Home > 4月, 2014

2014.04.28

サーバーの復旧完了しました。

今回のサーバートラブルは思いのほか手間取りました。

RAIDのHDDが壊れるというのは、季節的に暖かくなると風物詩のようなもので毎年大体一台は壊れることが多く、それ自体はそんなに気にしたことも無かったですが、

1.BadSectorが出ているHDDは一見正常に動いていて

2.サーバーボードのバグにより正常なHDDの認識がはずれ

3.このHDDを再認識させてRAID再構築中にこれまで陰に潜んでいた故障HDDの存在が発覚して2台同時にエラー

 

こういう経験は初めてなので色々とリペア作業も手間取りました。

その間サーバーが断続的にサービスを停止する必要があり、サイトにお越しになられた方には大変ご迷惑をおかけしました。

 

前回のblogで一旦強制的にバッドセクターが出ているHDDを強制的にRAIDに組み込んでまずはバックアップを実施し

6時間かけてバックアップも無事終了したので、リペアの開始です。

なお、今回のリペアでは写真に出ているCENTURYの裸族のお立ち台DJ クローンプラスが大活躍します。

 

バックアップを終えて、この後は定石として他のblogサイトでも紹介されているsmartctrlコマンドを使用してバットセクターの特定とddコマンドを使用してバッドセクターにゼロを書き込んで代替セクター処理を行うというもの。

ただ…smartctrlコマンドでバッドセクターの特定を行うのは非常に時間が掛かります

おとよも当初、定石通りに進めようとしたのですが、smartctrlのスキャン1回で3時間以上必要で、バッドセクター分実施するのですから非常に気が遠くなる作業です。 遅々として進まないsmartctrlコマンドのlongテストを実行しながら、ふと思いつきました。

・バックアップのときにエラー出なかったよね。

・つまりバッドセクターは、ファイルシステムの重要データにはかぶっていないんじゃね?

 

そう、ブランク領域でBadSectorがあるから、ファイルコピーではエラーが出ていない。

EXT4ファイルシステムのinode領域にもかぶっていない。 ならば、無理して代替セクター作成を行わなくても、交換用HDDに強制ディスクコピーを実施してその後でBadSectorは物理フォーマットで強制的に代替セクターを当てさせればいいんじゃないか…

ならば善は急げて、smartctrlを用いたリペアを中止して、ddコマンドを用いてHDDのクローンを作成準備です。

今回エラーを出しているのは/dev/sddディスク。

esataでつながっている裸族のお立ち台は/dev/sdgで認識しています。

# dd if=/dev/sdd of=/dev/sdg

 

とコマンドを入力するとコピーが開始しされます。・・・が、750GBのHDDをddコマンドでコピーするのは果てしなく遅いです。

3つのバッドセクターはRAID5ボリューム配置の関係からHDDの先頭80GB領域に発生していることはわかっています。

ddコマンドがコピーを開始してリードエラーでメッセージを出すのに約3時間掛かりました…あと9倍以上のコピー領域が残っていてこの時間経過は果てしなく長いです。

ddのコマンドリファレンスを確認するとddコマンドでコピーするときはデフォルトではセクター単位で512バイト毎にコピーをしているようですね。 バッファを大きく取って高速化することも出来ますが、それをするとバットセクターでエラーが出るとバッファ分全体がコピーされないらしく、これではバットセクターだけを回避してコピーすることが出来なくなります。

 

そこで登場するのが裸族のお立ち台DJ…

取扱説明書を確認すると、こちらは500GB HDDの全領域コピーで大体2.5~3時間となっています。 750GBでは1.5倍して5時間くらいでしょうか…ならばこちらのほうが早いということになります。

 

サーバーより/dev/sddの750GB HDDを取り外し

 

交換用のHDDも準備します。

サーバー構築当時は2.5HDDでNAS用の安価なモデルは無かったのですが、今回はWD-REDを購入しました。

 

そして、裸族のお立ち台DJにセットしてクローン実施。

 

予想通り5時間後にクローンが完了しました。

取扱説明書ではバットセクターがある場合コピーが停止すると記載がありますが、今回のクローン作業では停止せずにそのままコピーが完了しました。

 

そしてクローンされた交換用HDDをRAIDトレイにセットして、

 

サーバーに装着。

 

全セクターコピーを行っているのでパーティションテーブルやUUIDも丸ごとコピーされています。

サーバーはこのクローンHDDをオリジナルディスクと思ってRAIDボリュームに取り込んでくれます。

そして、サーバーボードの認識不良でRAIDディスクから外れていた/dev/sdeディスクをHOTADDします。

・・・・・やっとRAID5ボリュームが復旧しました。

 

ただそれだけではディスククローンが正しく行われていなかった可能性のチェックが出来ていないので、初めに実施したバックアップHDDを再度サーバーにつなぎなおして、diffコマンドで全ファイルを比較します。

約8時間掛かりましたが無事全ファイルの比較終了したので、VMwareも起動、公開サーバーを再起動してサーバーのリペアは完了です。

 

念のため、CentOSのディスクユーティリティにあるベンチマークテストを用いてRAIDボリュームをテストしてみます。

 

VMwareが稼動し、7つの仮想サーバーがこのRAIDボリュームに対してアクセスを行っていますので、ばらつきはありますが、最大270MB/sの転送レートが出ているので元の性能に戻っていると判断できます。

 

 

その後はエラーとなったHDDの処理です。

廃棄するというのも手なのですが、バックアップ作業などを通じてバットセクターが増加する兆しも特に無かったので製造時から持っていた不良なのかもしれません。 昨今は大容量化によるセクター数の増加に対応するほど品質が向上しているわけではないので、不具合発生率としては全体に増加傾向です。 一説には稼動初期3ヶ月で5%程度の不具合が発生するというデータもありますので、このHDDもそうなのかもしれません。

バットセクターを代替セクターに置き換える方法はいくつかありますが、すでに交換HDDが稼動していて復旧する必要はないのですからもっとも簡単確実な、物理フォーマット(全領域ゼロ書き込み)を行うこととします。

 

ウェスタンデジタル社が公開しているディスク検査ツールWindows用Data Lifeguard Diagnosticをダウンロードして、全領域ゼロ書き込みを実施します。

 

ダイアログ上では目安として約9時間必要と出ていますが、実際には12時間掛かりました。

特に書き込み時のエラーも発生していないので、代替セクター置き換えは成功したものと思います。

(ThinkPadにUSB接続でHDDを接続したので、SMART情報が読み出せない)

このHDDは万が一のときのために予備ディスクとして待機してもらいましょう。

 

結局作業時間としては述べ27時間以上近く費やした今回のRAID復旧も無事完了。

今回は初めてのトラブルだったので試行錯誤を繰り返しましたが、まぁ何とか無事に復旧出来てよかったです。

2014.04.26

サーバートラブル中

4月24日夜、blogをアップした際になにやらサーバーが重いようなそんな挙動を示していました。

仮想サーバーが重いのは致し方ないとしてもメインのサーバーはOSが動く分だけのCPUリソースを割り当てているのでおかしいなぁ…と中を覗いてみると、データドライブのRAID5ボリュームのHDD1台がエラーを出して停止しています。

 

/proc/mdstatを見たところ、/dev/sdeドライブが見当たらないように見えます。

/dev/md0と/dev/md1の両方のRAID5で障害が出ていることから、どうやら/dev/sdeドライブ自体が何かしら障害を発生した模様。

ただ、この親サーバーで使用しているマザーボードIntel製S1200BTSは起動時にまれにHDDを認識に失敗するというバグを持っています。 前回(日曜朝)のcron実行で再起動した際に認識に失敗したやも知れません。

 

ならばシステムを再起動して再認識するか確認してみよう…ということで、システムを再起動すると今度は/dev/sdeを正しく認識してくれます。 よしよし、では/dev/sdeをRAIDに組み込もう・・・と

# mdadm –add /dev/md0 /dev/sde1

# mdadm –add /dev/md1 /dev/sde2

と打ち込んでリペア開始。

 

ちょうどこのmdstatをキャプチャした後、悲劇が起こります。

まったく正常に見えていた/dev/sddドライブ…厳密には/dev/sdd1のパーティション領域にバッドセクターが潜んでいました。

そのため、リカバリに失敗するのと同時に/dev/sdd1もHDD不良として認識し、/dev/md0はHDD2台が不良という状況に。 /dev/md0は仮想サーバーのデータが入っていますので、この段階でVMwareはエラーで順次サーバーが停止していきます。

もう最悪の事態です。

 

ディスクユーティリティで確認してみると、SMARTデータにしっかりと警告が出ています。

これは何とかせねばいけませんが翌日は金曜で会社もありますので、一旦サーバー全体をシャットダウンして翌朝会社に向かいます。

また修復作業するにも少なくとも/dev/sddドライブはバットセクタのリペアが出来るかどうかは不明なので、予後のHDDをAmazonに発注。 こちらはその日の夜に到着。 相変わらずAmazonすごいですね。

 

そして今日より復旧開始。

まずリペアする前は正常にRAIDは動作していたのですから、とりあえずリペア動作さえしなければ何とかなるはず。

なのでとりあえず下記コマンドを打ち込んで強制的にRAIDを復活します。

# mdadm –stop /dev/md0 →RAID停止。

# mdadm –assemble –run –force /dev/md0 /dev/sd[cdef]1 →強制的にRAIDマッピング

/dev/sde1はリカバリ出来ていませんので、マッピングは出来ていないようですが、とりあえずは昨日の状態まで戻りました。

 

ただここから修復するにも、万が一のことを考える必要があります。

バッドセクタのリペアを実施して、HDD自体が逝ってしまったら…今のところ問題なく動作している/dev/md1が巻き添えになる可能性もあります。このRAIDボリュームは家族の重要データ(写真とか色々)が入っているのでそれは避けねばなりません。

よって現在は2TBの大容量HDDで現在RAIDにあるデータをすべてバックアップ中です。

 

バックアップが完了したらHDDのリペアにあたろうと思います。

2014.04.24

通勤カバンを買い直しました。

今回は変わったところで、通勤に使用しているカバンについてです。

おとよは会社よりノートパソコンを貸与されているのと持ち出し許可を頂いているので、通勤での会社と家の往復や業務で社外に出るときにノートパソコンを持ち歩いています。

職業柄東京出張が比較的多いので、出張での移動も回数を重ねていくと旅というより普段の通勤の感覚になってきます。

そのため出張の為に専用にカバンを持ち変えるというのは結構手間なので、宿泊出張時でない限り基本通勤時のカバンのままで行動します。

そうすると必然的に通勤カバンに求めるの性能はデザイン性よりも収納性と耐久性が最優先になります。

 

現在使用しているカバンはMANHATTAN PASSAGE “ゼログラヴィティー”ブリーフケース #2470を使用しています。

B4サイズで、13インチのノートパソコンが収納可能な緩衝材入りポケットを装備したカバンですが、MANHATTAN PASSAGEの同クラスのカバンではもっとも軽量なモデルです。

MANHATTAN PASSAGEといえばドラマ・大踊る走査線 THE MOVIE3で青島刑事が使用したカバンということで有名になりました。 あちらは#2190 ”Mr.Lau”ビジネストリッパーというモデルですが、基本的なフォルムは大体共通です。

 

約7年前に購入したこのカバンはおおよそ120~130回に及ぶ出張でも活躍してくれました。

新幹線・飛行機と色々な移動手段で共に移動しました。

しかしながら形あるものいつか壊れるもの、フロントポケットのファスナーが壊れてしまいました。

 

肩掛けベルトや全体のつくりはくたびれてはいても、ナイロン繊維のほつれ等まったく無くまだまだ持ちそうな感じです。

 

そのためファスナーを交換すれば修理も可能かと思いましたが、7年も使用したのですからこの際買い換えることにしました。

しかし買い換えるとなると欲が出るもので、今以上の鞄を求めてしまいます。

もちょっとカッコいいカバンを・・・とも考えましたが、やはり仕事で使用するのですから、機能性、収納性そして信頼性です。

 

因みに現在使用しているカバンには下記のものが基本装備として入っています。

1.ThinkPad220 + ACアダプタ + マウス

2.モバイルバッテリー + モバイル機器接続用USBケーブル一式

3.移動時の友、Kindle PW 3Gと3DS LL

4.事務仕事の友、ノート&ノートカバー + 筆記具 + 電卓

5.ipod + ヘッドフォン + Bluetoothヘッドセット

ほかにもUSBカードリーダー + USBメモリを装備しています。

これらをカバンに入れると、大体7Kgくらいの重量になります。

 

この重量物を担いで移動し、かつ年単位で破損しない事を条件に有名カバンメーカー等、色々探しましたが…うーむ。  どんなにこだわった作りでも多くの場合は1年程度で壊れそうです。

やはり機能性とデザイン性重視なのか、たくさんの荷物を担いで長距離移動することを前提とされていないようです。

 

たとえばカバンの開閉に金属スナップを採用しているモノは、おとよとしてはナンセンス。

開閉しているうちに確実にゆるくなります。 面ファスナーも同様です。

この手の固定具を重要な開閉部に用いてるカバンは、どんなにこだわっているとうたっていても個人的には駄目です。

100回も開閉したら信頼性がなくなるので仕事には使えません。

 

また永久修理保障などの特典はあまりプラスポイントになりません。

短期間で修理が必要な事態になるより、長期間安定して使用できることのほうが優先だからです。

 

結局条件に見合うカバン…とネットを徘徊して、元のMANHATTAN PASSAGEで探すことにしました。

軽量で収納性・耐久性と考えると、やはり”ゼログラヴィティー”シリーズになるのかなぁ・・・とカタログを見ていると、なんと今使用しているのとまったく同じ#2470モデルが販売されています。

7年経過しても販売されているのは驚きですが、それだけ人気と実績があるということなのでしょう。

今回、新しいカバンを入手するという感動を期待していたのも事実ですが・・・冒険心がないですね、結局同じモデル#2470を直営店に楽天経由で発注しました。買い直しです。

 

そしてブツはあす楽対応だったので発注した翌日に配達されてきました。

 

開封の儀という程ではないですが・・・一応開封です。

うーん…個人的にはいつか見た光景なのと、見覚えのあるカバンなので感動は薄いですね。

 

新旧並べてみました。 左が現在使用しているもの、右が購入した新品。

やはり古いほうは全体にヨレヨレ…という感じがしますね。

 

フロントポケットに縫い付けられている、メーカーロゴの赤いタグを比較。

右側の新しいタグが圧倒的に綺麗です。

 

中を開いて比較。

左の古いほうは生地がくたびれた感はありますが、破損するとかそういう心配はまだまだなさそうです。

右側の新品と比べても著しく劣るという印象はありません。

7年経過してこれなのですから耐久性は申し分ありません。

 

そして新しいカバンに荷物を入れなおしてみました。

流石に全体的にシャンとしていますね。(笑)

ファスナーの開閉もかなりスムーズで、同じカバンとはいえ使い勝手は格段に良くなりました。

 

やはり古いほうはファスナーの開閉が数千回に及ぶほど酷使されてきたのですから、当然といえば当然ですね。

この新しい、#2470 “ゼログラヴィティー”ブリーフケース にまた数年お世話になろうと思います。

 

2014.04.18

Xperia Z1f(SO-02F)のdocomo ID認証エラー、その後

Xperia Z1f(SO-02F)でカスペルスキーインターネットセキュリティが提供するWEBプロテクションを設定すると、WiFi利用時にdocomo ID認証がエラーとなる症状のその後です。

 

2014/03/31にSO-02Fのソフトウェアアップデートされたのと、カスペルスキーインターネットセキュリティも最新版(Ver.11.3.25.1)が公開されていましたので双方最新版へ更新し、カスペルスキーのWEBプロテクション機能を敢えて有効として、WiFi接続モードで本体の電源をOFF/ONを行いシステム起動時の発生するdocomo ID認証エラー発生が対処されているか確認してみました。

 

結果は・・・残念ながら以前と同様、WiFi接続モードでシステム起動してくるとdocomo ID認証でエラーが発生します。

残念ながらWiFi接続モードでシステム起動した際に発生するdocomo ID認証エラーは今のところ回避されていないようです。

 

残念なり。

2014.04.13

Next Launcher 3D Shell を導入しました。

 

ELUGA V P-06DからXperia Z1f(SO-02f)に機種変した際、ホームアプリはP-06Dから使用していたAPEX Launcher proをそのまま使用していました。

 

APEX LauncherはICS(Android 4.0)のホーム機能を利用して利便性を良くするように拡張されたホームアプリです。

Androidが持っているホームの機能を利用しますので、Android4.0以上が利用の条件ですが、ホームアプリ自体は比較的軽く、また安定度もかなり高いのが特徴です。 ただAndroid純正ホームを拡張しているので、Androidがホーム機能で実現できること以上に拡張することは困難なのか、このタイプのホームアプリは機能拡張の限界に来ているように思われます。

また処理状況をBatteryMixで見ると確かにアプリ自体は処理として軽いように見えますが、AndroidシステムやシステムUIといったAndroid本体の処理が重くなりがちです。 つまりアプリは軽くともシステムの処理が重くなっているのでトータルで見て軽いというわけではないということになります。

 

そう思うといっそシステムUIに依存しないホームアプリのほうが良いのではないかという気がしてきました。

APEX Launcherを利用する前は処理として軽いといわれるLauncher Proを使用していましたが、こちらはもう更新がされなくなって2年ほど経過します。

Android4.xでも問題なく動作しているようですが、更新がとまったホームアプリを使い続けるのはあまり感心しません。

 

よって最新のホームアプリに乗り換えるべく検討開始です。

最新ホームアプリは色々あり、機能重視・軽さ重視・個性重視等Android4.0以降はさまざまなものがリリースされています。

とりあえず無償版が準備されているものを試してみて、機能の豊富さと拡張性、省電力性能が考慮されているものを選んでみました。 すると、意外というか今回テストしたものではNext Launcher 3Dが省電力性能が高く、実使用上バッテリーに優しいホームアプリという結論になりました。

 

Next Launcher 3Dは高機能に定評のあるGO Launcher EXの次世代ホームとして作られたもので、3D描画機能を駆使した画面エフェクトを実現したホームアプリです。

 

しかしながら無償版が利用期間の制限がある試用タイプのアプリであること、機能解除される有償版が1,500円以上するAndroidアプリとしてはかなり高額な部類に入ることから人気としてはいまひとつ。 利用方法など検索しても無償利用できるGO Launcherの方がレビューが多く、日本で利用している人はそれほど多くないようです。

 

Next Launcher 3Dの前身NextLauncherが公開される前は、3DホームアプリといえばTSF Shellが有名でした。

高機能でかつ派手なエフェクト表現力は申し分ないものです。 以前TSF Shellを購入しライセンスを保有していましたのでNextLauncher 3Dのテストの前にこのアプリを評価しましたが、このホームアプリは待機時もバッテリーを消費します。 スリープ時もアプリ自体は更新を繰り返しているのが原因なのか、省電力という目的ではこのホームアプリはよろしくないようです。 そのためテスト当初Next Launcher 3Dも処理が重く、バッテリーには厳しいホームアプリだろうと予想していました。

 

実際に使ってみると、NextLauncher 3Dは動作時…特にテーマ入れ替え等のカスタマイズを行っているときは重い処理を実行しているのかバッテリーを盛大に消費します。しかし通常動作に入ると処理としてはそれほど重いものではなく、スリープに入ると画面描画などが停止するようです。 これは待機時の省電力性能に期待が持てます。また、SO-02fのスタミナモードでこのアプリをスリープ時の機能制限対象に指定できることもポイントが大きいです。(APEXは指定できない)

 

そして長時間テストしてみようと、

昨日(11日06:00)に充電を解除して会社に出勤

勤務中はいつも通り通話で利用(全体で1時間くらい)

Twitterに投稿・確認、アマゾンアプリで買い物に利用

ドコモメールやGmailの送受信は40通前後

上記のようにスマホとして普段通り使用して42時間後になる13日00:00にBatteryMixを確認したのが下記。

 

42時間経過して56%のバッテリー残量があります。 単純に倍掛けして84時間=3日以上は持つ計算です。

このスコアはAPEX Launcherでは出たことがありません。

 

そしてバッテリーの消費状況を確認すると、APEX Launcherではこれまでの経験では2-5%くらいの処理利用率ですが、NextLauncher 3Dでは8-9%位とかなり利用率が高いスコアを出しています。

 

これはシステムUIなどの処理に依存せずホームアプリ側でかなりの処理を肩代わりしているのですから致し方ないことです。 ただ利用率が高いというのは全体を通してなので、全体のバッテリー消費が少なければ利用率が高くとも問題ではありません。

そこで消費状況をグラフで確認してみます。

 

全体消費がかなり低いことがわかります。

おそらくスリープ時の省電力がかなり功を奏しているのでしょう。

SO-02fのスタミナモードで機能制限対象にした効力も大きいと思います。

 

今回採用したNextLauncher 3Dはホームアプリ側で多くの処理を実現していますので、まだまだ伸びしろが見込めるアプリです。

余白設定などのAPEX Launcherで出来てNextLauncher 3Dでは出来ていない機能もまだありますが、バッテリーの持ちも良いですし今後に期待してこのままメインのホームアプリとして利用してみようと思います。

1 / 212