ただつらつらと日記が書かれていくようです。

カテゴリー: ITめいたこと (20ページ目 (31ページ中))

RMAしたHDDがまた壊れた。

Seagate製のHDDには、RMA(Return Merchandise Authorization)という保証が付いている。HDDが出荷されてから一定期間の間、故障した場合などにSeagateにHDDを返品すれば、新しいHDDを提供してもらえるという仕組み。

先日、Barracudaのサーバー向けのHDDが見事に故障したので、SeagateにRMA申請して、シンガポールまでHDDを返品(実際に送ったのは、千葉県某所の倉庫までだけど)して、別のHDDを送ってもらった。んで、送られてきたのはHDDのシールが緑の線で縁取られた「Seagate Certified Repaired HDD」。結局のところ、別のユーザーがSeagateに返品して、Seagateが修理したHDDが送られてきた、というわけだ。とはいえ、なんとなーくまともな用途に投入するのは躊躇われたので、NASのバックアップデータを保存するHDDとして、外付けUSBケースに入れてNASに接続してたら…3000時間ほどの稼働時間で壊れた。NASがバックアップを実行して、RAID上のデータをそのHDDに書き出そうとするとエラーメッセージが出てしまう。

壊れ方としては、データを読み込もうとするとRead Errorが出てしまう感じ。NASからHDDを外して、Linuxマシンに接続して、smartctlからself testを実行してみるものの…残り90%ほどのテストルーチンを残してエラー終了。あぁ、なんかもうダメだ。

壊れたCertified Repaired HDD

いやはや、読み書きするデータ量が一定ではないにしろ、20000時間経過しても壊れないドライブもあれば、3000時間ほどで壊れちゃうドライブもあってなかなか興味深い。…しかし、送られてきたHDDって「Certified Repaired」じゃないのかと。やっぱ、例のSeagateのファームウェア問題を抱えた世代のHDDはダメなのかなと妙な結論に至りつつ、代替のHDDとして、Western DigitalのHDDを発注した。

HuaweiのE585のバッテリー。

なぜだか手元にHuaweiのE585がある。(ま、SIMロックフリーだとか、直輸入とかなんだかよくわからんけれども、とりあえず手元にHuawei製のモバイルルータのE585がある)

で、このE585は1年前から使われているらしく、バッテリーがへたってきており…バッテリー交換できないかと頼まれたものではあるが、その辺でE585用のバッテリーなんて売ってるはずもなく、途方に暮れていた。

そこで、とりあえず、同じHuawei製のモバイルルーターならバッテリーが互換するのではないかということで、一縷の望みにかけて、DoCoMoの「HW-01C」(E585と同じく、同じHuawei製)用のバッテリーである「HW01」を取り寄せて購入してみた。(なんとなーく、使えそうな予感はしたので…汗)

で、とりあえず、E585に装着してあるバッテリーと交換して、E585の電源を入れてみたところ、何事もなく起動した。E585をUSBに接続して充電を試みたところ、インジケータ的には充電も行われているらしい。ま、互換してたってことだろうか。

DoCoMoが扱っているバッテリーであれば、多少、取り寄せなどに時間はかかるかもしれないが、入手不可能っていう状況には簡単にならないだろうな、と。それに、1,800円(確か、「HW01」ってこれくらいの値段だった気がする)という値段も高くないと思う(こういうITガジェットを扱っている輸入業者の中には、こういう消耗品で儲けちゃおうと思っている人たちも少なくないような気がする)

IIJmioの「IIJmio高速モバイル/Dサービス」を契約してみた。

会社で日本通信の「b-mobile fair」のSIMを何枚か使っていて、そろそろ有効期限切れのSIMがちらほらあるということで、「IIJmio高速モバイル/Dサービス」のSIMカードを調達してみた。

f:id:y_fudi:20120303155210j:image

「IIJmio高速モバイル/Dサービス」って。

最近、サービスインしたばかりの「IIJmio高速モバイル/Dサービス」はDoCoMoの回線を使ったMVNOなサービスで、売りは「LTE」に対応した高速通信が可能ってことではあるんだけど、よーく見てみると、FOMA対応端末に刺せば、それはそれで使えるらしいと。

とりあえず、既存のFOMA対応の端末を使って使う前提で「IIJmio高速モバイル/Dサービス」を眺めてみたけど、それなりにメリットがありそうだ、と。「IIJmio高速モバイル/Dサービス」には、2つのコースがある。いずれのコースも高速通信が可能なデータ容量が決まっていて、それを消費すると128kbpsの速度制限がかかるというサービス。ま、128kbpsで良ければ使い放題のサービスとも言える。

1つは、「ファミリーシェア1GBプラン」。3枚のSIMを発行してもらって、月額1GBの(高速通信可能な)通信容量をシェアするというもの。これで月額2940円(初期費用は3,150円)。1GBで足りなければ、100MBを500円で購入することになる。2つめは「ミニマムスタート128プラン」。1枚のSIMで、月額945円。こっちはあらかじめ高速通信可能な枠がないので、上記のとおり、100MB分を500円で購入することになる。

「b-mobile fair」と比較。

現在、使っている「b-mobile fair」も悪くないサービスだが、今の使い方に合ってない部分がないわけでもない。例えば、複数枚のSIMカードを複数のモバイルルータに刺して使っているが、人によって実際に使っている通信量が異なっていて、その通信料に割と幅がある。例えば、月に100MBちょっとしか使ってない人も居れば、300MBちょっと使っている人がいる。前者の場合は、有効期限切れを待つことなくチャージを行う必要があるし、後者の場合は、有効期限切れでチャージすることになるが、実際はかなり通信可能な容量が余っているということになる。

そんな現状を鑑みて、大量に通信をする人と、ほとんど通信しない人の間で通信可能な容量をシェアできれば効率的なのだが、そういうわけにはいかないのが「b-mobile fair」。いや、まぁ、どっちかというと「b-mobile fair」の仕様が普通ではあると思うが…。そんなこんなで、通信帯域を絞られるのも辛いから、多少は金を支払うけれど、使い放題ほどの料金は払いたくなくて、できれば、複数枚のSIMの利用を前提に最適化されたサービスを探していたのだが、まさに「IIJmio高速モバイル/Dサービス」が適合しているように見えた。

コスト比較をしてみると

前述のとおり、通信量にばらつきがあるので単純にコストを比較するのは難しいが、仮に(A)月に300MB通信するSIM、(B)月に200MB通信するSIM、(C)月に100MB通信するSIMの3枚のSIMを1年間使うようなユースケースを想定する。

「b-mobile fair」だと、120日間、もしくは(そのSIMで)1GBの通信を行うことで使えなくなる。よって、(A)だけが容量が理由で3ヶ月で更新する必要がある一方、(B)も(C)も120日間=4ヶ月間使える。よって、新規も更新も9,800円だとすると、(A)は4回更新する必要があるので、9,800円x4=39,200円。(B)も(C)も3回の更新でいいので、9,800円x3=29,400円になる。よって、3枚のSIMで98,000円。

一方、「ファミリーシェア1GBプラン」だと、3枚のSIMの月あたりの通信容量は100MB+200MB+300MBなので、1GBで収まっている。追加容量を購入する必要はないため、月額費用については2,940円から変動しない。よって、1年間運用したとして、2,940円 x 12 = 35,280円。その差額は62,720円。半額以下の64%offになってしまった。…思ったよりも大きな削減が可能なのかもしれない(汗)

値段だけなのか、と。

値段の比較からすれば、大丈夫かと思ってしまうし、サービスイン直後のサービスは少々不安ではあるが、もともと個人向けのサービスを使っているわけだから、サービスレベルなどもそんな高度なことは期待できないと思っていれば、大きな差もないのではないかと思わないでもない。

それに、b-mobile fairはグローバルIPをDHCPでダイナミックに割り当てている一方で、IIJmioのサービスはSPモードと同様にNATでサービスを提供しているらしいので、微妙な仕様の差もある。しかし、フツーに使ってみて、どっちもそこそこな品質のサービスであれば、安い方を選んでしまうのが人情ってもんだろうな。

なんか安いのでIIJmioの回線が混んでこないか…なんとなく心配ではある。

ThinkPad X61のバッテリーを買ってみた。

今更、なにやってるんだろうと自分でも思うが、中古のThinkPad X61を買ってきた。

ま、建前上は、Ubuntuを動かしていたThinkPad X32が本格的に壊れたから、その代替機なのだが、代替機という意味ではMacBook Airを買ったので、ThinkPad X61は何を代替しているんだろうという感じではある(汗)

ま、そんな動機はともかくとして、秋葉原に出かけて中古ショップで買ってきたThinkPad X61は16,000円。正直、思ってたよりもかなり安かった。中古のノートPCなのでバッテリーについては文句を言えないことくらいは知っているが、店員が謎の解説をしてくれたので記録しておこう。

店員:「今から、バッテリーを入れて、ブートしますねー」
(しばらく待ち)
店員:「えーと、Windowsが起動しました。で、バッテリーが70%残ってますね」

ま、ここまではいいとして。

店員:「ま、70%残っているので、なかなか良好ですね」

…えっ?そもそも、いつ充電されたかわからんバッテリーだし、その時に満充電されたかどうかもわからんのだから、バッテリーの寿命的なことは、ブートしただけではなんにもわからんではないか。しかも、満充電してあったバッテリーを使ってブートしただけで70%になってたら、それはとんでもなく劣化したバッテリーではないか…などと考えること、数秒。

私:「あ、はい。わかりました」

いや、わけわかんないって言ってモメることもできたが、もう面倒だった(嫌なら買うなって結論にしかなんないわけだし)で、家に持ち帰って、ACアダプタをつないでみると、ThinkPad X61のバッテリーランプはオレンジ色に点滅。バッテリーに異常があるってことだ。…やっぱり、劣化しつくしたバッテリーだったということだろう。安かったから仕方ない。

そんなわけで、X61のバッテリーを買うことにしたものの、Lenovo製の純正品など高すぎて変えるわけもない(本体価格に匹敵する)。かと言って純正品の中古品なんか買ってみたところで、同じことが起こるだけだろうから、互換バッテリーの新品を探すことにした。

で、探しあてたのが、ROWA JAPANってところの互換バッテリー。SANYO製のセルを使った互換バッテリーでだいたい3000円。X61の保証なんかはもともとないので、互換バッテリーでも問題ないだろう。で、楽天のROWA JAPANのページを見てみると、X60対応バッテリーって書いてあるけれど、X60に対応している「40Y7001」の互換品なら、X61にも対応しているはずなんだけどなぁ。ま、とりあえず、ThinkPad X61を使っていて、もう保証が切れてどうにでもなれモードの人にとっては、互換バッテリーも意外と選択肢に入るのではないか、ということで。

発注はしたもののまだ届いていないので確かなことは言えないが、確かX61のBIOSって、起動時にささっている周辺機器(HDDとかバッテリーとか)が純正品かどうかチェックするような処理が入っていなかったっけ。ま、そうだったら、起動するたびに余計なアラートが上がることになるだろうなーということで(汗)

[amazonjs asin=”B000BUNVF0″ locale=”JP” title=”Lenovo ThinkPlus トラックポイント・キャップ・コレクション 73P2698″]

So-net blogのSSL証明書が期限切れ。

So-net blogに貼ってあるリンクを調整しようと思ってアクセスしてみたら、派手にSSL証明書の有効期限が切れておりました。まさに、今朝、expireしたばかりのようですね。いやはや。

ま、SSL証明書の有効期限管理は手間臭いよね、ということで。有効期限の短いSSL証明書をいくつも管理しなくちゃならん身としては、他山の石とさせていただこうかと。

f:id:y_fudi:20120126114402j:image

追記:

So-net blogの障害情報を見てみると既に対応中だったようで。→【対応中】セキュリティ証明書の警告について

有効期限切れの証明書でも技術的にはOKってのは確かにそうなのかもしれないけれどブラウザとサーバ間は暗号化されるもんなぁ、一応*1も、ただ、あのSSL証明書の警告画面が出たら何でもOK押せって意味ではないこと(SSL証明書の警告画面にはそれなりに意味があること)をわかってもらう必要はあるのかもなぁ、と。

*1:ブラウザとサーバ間は暗号化されるもんなぁ、一応

badblocksにてHDDの検査中。

ddを使ってドライブの隅から隅まで読み書きのテストをしていたHDDのSmartの「Current Pending Sector Count」に2が記録されていた。んで、dmesgにはこんな感じでエラーが記録されていた。

sd 5:0:0:0: [sdb] Unhandled sense code
sd 5:0:0:0: [sdb] Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
sd 5:0:0:0: [sdb] Sense Key : Hardware Error [current]
sd 5:0:0:0: [sdb] Add. Sense: No additional sense information
sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 03 ff 8b 00 00 00 f0 00
end_request: I/O error, dev sdb, sector 67078912
__ratelimit: 20 callbacks suppressed
Buffer I/O error on device sdb, logical block 8384864
Buffer I/O error on device sdb, logical block 8384865
Buffer I/O error on device sdb, logical block 8384866
Buffer I/O error on device sdb, logical block 8384867
Buffer I/O error on device sdb, logical block 8384868
Buffer I/O error on device sdb, logical block 8384869
Buffer I/O error on device sdb, logical block 8384870
Buffer I/O error on device sdb, logical block 8384871
Buffer I/O error on device sdb, logical block 8384872
Buffer I/O error on device sdb, logical block 8384873

うーむ、Buffer I/O error。なんか嫌な予感がするので、badblocksに切り替えて(今思えば、最初からbadblokcsを使っておけばよかったな)破壊検査を実施。これは時間がかかりそうだ。

久しぶりにAWSのManagementConsoleを開いたら、Dynamoが使えるようになったっぽい。

昨日、AWSのEBSのバックアップを取得するべくManagementConsoleにアクセスしたときには気づかなかったが、タブの右端に「DynamoDB」ってタブが増えていた。

AWSのDynamoというと…確か、Amazon製のKVSって印象だけど…ちょっと調べてみたら、Amazonの買い物カゴ機能の裏側でDynamoががんばっているらしいのだが、そんなKVSをAWSユーザーに解放するってことか。ぼんやりとどんな使い方ができるか考えてみよう。

HP製SmartArrayのRAID Arrayの監視とか。

古くからのHP Proliantユーザーにはアタリマエのことかもしれないが、新参者のProliantユーザーにはよくわかんないことが割とある。例えば、SmartArrayカードで組んだRAID Arrayの監視だ。

RAIDの管理コマンドを使えば、RAIDの設定などが割と簡単にできることはわかったけれども、どうも監視についてはどうもピンと来ていないたぶん、ドキュメントは存在している感じだが、まとまった形でドキュメントが用意されていないような気がするのが原因ではないか(*1)。どうやら、IMAなるものをインストールすれば、ハードウェアの監視を一括で引き受けてくれるっぽい。で、何か起こったら、rootへのメールと、/var/log/messageへの書き込みを行なってくれるらしい実際にメッセージを書きだすのはIMAの構成モジュールのASRらしいが(*2)。

ただ、なんとなくここまで大掛かりに監視したくないような気もする。監視用のエージェントがメモリとかCPUとか食わないだろうかといった心配もあるし、単にRAIDがコケてないことを確認したい場合の選択肢がないか、と探してみたら、SourceForgeにccissドライバと共に公開されている「cciss_vol_status」ってアプリケーションを使って、RAID Arrayのステータスを取得して、そのメッセージをどうにかすれば監視ができそうだ。

例えば、「cciss_vol_status」を実行しつつ、メッセージを取得して、取得した結果がおかしなことになっていたらアラートを上げるみたいなシェルスクリプトをcronで定期実行するのもありかなぁという気もする。

で、試しに「cciss_vol_status」をビルドして実行してみようとしたら、「/dev/cciss/c*d0」なんてデバイスが存在しないのだった(汗)Scientific Linux6を使っている関係で、ccissドライバではなく、hpsaドライバが使われているせいだろうけれど。。。で、ドキュメントを読んでみたら、hpsaドライバを使っている場合は、scsi genericデバイスが割当てられるらしく、「cciss_vol_status /dev/sg0」とかやると、RAID Arrayのステータスが返ってきた。ま、あとはシェルスクリプトを書くだけ、と。

*1:たぶん、ドキュメントは存在している感じだが、まとまった形でドキュメントが用意されていないような気がするのが原因ではないか、と

*2:実際にメッセージを書きだすのはIMAの構成モジュールのASRらしいが

HDDのエージングってどうしたものか。

新たにサーバを構築しようとなって、HDDを調達してみたものの…これ、どうやってエージングするのが正しいのだろうか、と考えると、結構面倒くさいことになりそうな気がしてきた。

例えば、ddでディスクの隅から隅までをゼロフィルしたとして、その間に書き込めないセクタが見つかればエラーを検出してくれそうな気がする。一方で、読み込みの方は、例えば、ifに検査対象の/dev/sdXを指定することで、/dev/sdXから読み込んで、/dev/nullに書きこんであげれば(…といっても電子空間の狭間に消えて行くわけですが)、また、HDDからの読み込み中にddが読み込めないセクタに直面したら、きっとエラーが検出されるだろう(てか、検出して欲しい)

一応、テストにはなりそうな気がしてくるものの、1回、隅から隅まで読み書きしただけでOKとするのも心許ないような気がするので、読み書きを何回かくりかえすことになりそうだ。しかも、この手のテストは、隅から隅までHDDを舐め回すので、1本のHDDを処理するのにさすがに時間がかかりそうだ。しかも、RAID1+Hotspareなサーバが2台だから、テストすべきHDDは6本。orzあとは、1台のPCに複数台のHDDを接続して、同時並行でテストするしかないかと…。

MySQLサーバでインデックスが使えないとどうなるか。

ちょっとした理由でMySQLの大きめなテーブルにてインデックスが使えない状態となった。さて、そんな時、MySQLサーバのCPU使用率などはどんな傾向を示すのだろうか。…いや、わかりきっているんですけども

…というどっちでもいいことをGangliaのグラフから拾ってみた。一応、インデックスの復旧を頑張っていたので、使えていた状態から使えなくなる部分の差異は拾えなかったので、インデックスが効かない状態だったから、インデックスが有効になって使える状態に遷移した時のGangliaのグラフを。

まず、CPU使用率のグラフから。とある時点から、グラフの面積が明らかに小さくなっていると思うが、そこで、indexが復活している。

f:id:y_fudi:20120113173935j:image

indexが効いていない間は、MySQLがCPUを使っているので、CPUのUserがぐーんと使われることになり、インデックスが効けば、きゅーんと下がる。

f:id:y_fudi:20120113173936j:image

んで、当然のことながら、load averageはCPUの使用率に追随してくれる感じなので…。

f:id:y_fudi:20120113173937j:image

15分のload averageは思ったよりもわかりやすく見えるなぁ…。これまた、わかりきったことではありますが、RDBMSにおかれましては、インデックスの存在は極めて重要だな、というわかりきったことが改めてわかった次第でございます。

« Older posts Newer posts »