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

月: 2012年1月 (1ページ目 (2ページ中))

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″]

はてなでSSD祭りが盛大に開催されたらしい。

週末、はてなのサービス各種が「データベースサーバのハードウェア障害」を理由に、サービス停止に陥っていた。とはいえ、いくつものサービスがどーんと落ちるデータベースサーバのハードウェア障害ってのは、簡単には想像しづらい(簡単に思いつくような障害点は、既にそれなりに対策がなされているはずだろうし)

で、はてなCTOの田中さんのこのTweet。

[oEmbedTweet 163155954404298752]

SSDが通電5000時間で軒並み死んでいく…これはなんとも恐ろしい障害だ。おそらくは、ソフマップがファームウェアの更新情報を出していた「Crucial m4」の新ファームウェアを導入できていなかったんだろう。それで、各サーバが決められた時間を超えて死んでいく…南無南無。

というか、通電時間が一定時間を超えると死ぬってファームウェアのバグはなんとも痛いなぁ。しかも、再現率100%。いつかのSeagateのHDDのファームウェアのバグは、再現率100%ではなかった気がする(えーと、リブートして運が悪かったら…ってな感じだったかな、と)ま、こういう事象を聞くと、SSDってどうなんだろうと思わないでもないが、速いものは仕方なく、結局のところ、こんなバグが見つかったとしても使わないって選択肢はないんだろうけれど。

こういうリスクは、使うSSDのベンダーを分散するとかって方法論で連鎖的なサーバダウンは回避できそうだけど、普段のオペレーションに影響はないんだろうか。例えば、いろんなSSD混ぜてRAID組むとか。ま、この手のことはやってみないとわかんないことが多くて困るなぁ。

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:ブラウザとサーバ間は暗号化されるもんなぁ、一応

マクドナルドのTwitterマーケティングで炎上。

TwitterのTLより。

マクドナルドのキャンペーン

イギリスの「The Telegraph」にこんな記事「McDonald’s #McDStories Twitter campaign backfires」が載っている。どうやら、マクドナルドがTwitterを使ってキャンペーンを実施したらしい。「#McDStories」ってハッシュタグを使って、マクドナルド的深イイ話を流すつもりだったようだ。ま、おそらくはイメージ向上のためのキャンペーンってところだろう。

で、これが完全に炎上したってことで何が起こったか。

ハッシュタグの着火点

そもそもは、「#MeetTheFarmers」ってハッシュタグを使って、マクドナルドの食材を作っている人たちがどんなに頑張っているかについてTweet
をしたところから始まっているようだ。きっと、「#MeetTheFarmers」を使ったキャンペーンは何事もなく終わったのだろう。それで味をしめたマクドナルドは、第2弾として、ハッシュタグ「#McDStories」を使って、今度はマクドナルドでハンバーガーなどを提供するために頑張っている人たちのお話を流そうとした。

で、マクドナルドの担当者が2回ほどハッシュタグを使って投稿したあたりで事件は起こった。マクドナルドの担当者ではなく、Twitter
のユーザー(本来であれば、マクドナルドからのTweetを眺めることを期待されている側の人たち)が「#McDStories」を使って「My brother finding a fake finger nail in his fries.」(フライドポテトの中につめが入ってたのを兄弟が見つけた)なんてつぶやき始めた。さらに、マクドナルドを解雇された話や、マクドナルドの商品を食べておなかを壊したといった話が「#McDStories」を使ってつぶやかれ続けてしまった。マクドナルドが「#McDStories」を使って、意図したTweetができたのはわずか2回。あとは結局、マクドナルドにとっては完全にネガティブキャンペーンになってしまった…と

ハッシュタグは計画的に

ま、当たり前だけど、ハッシュタグは一方的なキャンペーンばかりでなく、誰でも使えるものなのでご利用は計画的に、ってところだろうか。しかし、簡単にネガティブキャンペーンにひっくり返されてしまうほど、イギリスのマクドナルドは恨みを買いまくっているんだろうか(笑)

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ユーザーに解放するってことか。ぼんやりとどんな使い方ができるか考えてみよう。

SuicaポイントクラブのポイントでSuicaチャージバック。

JR東日本は、モバイルSuicaや記名式のSuicaなどを対象に「Suicaポイントクラブ」なるものを運営している。

ま、端的に言えば、ポイントクラブに登録してあるSuicaを使って、駅ナカなど乗車券以外の使い方でSuicaのStored Fare=SFを使うと、利用金額に応じてビミョーにポイントバックされる仕組みで、さらに、そのポイントはWAONやYahoo!ポイントなどに移転することもできるし、Suicaにチャージすることもできるという仕組みである。

…と、そんなわけで、久しぶりに何ポイント貯まっているか確認してみたところ、250ポイント。なかなかビミョーな量である。何を勘違いしたのか、Suicaポイントクラブの1ポイント=Suica10円分くらいでチャージされるのかと勝手に期待していたら、Suicaポイントクラブの1ポイント=Suica1円分。つまり、私のキャッシュバックは250円であった。勝手に期待したのは私だが、なんとなく残念な感じだ。250ん円分でもないよりはマシの精神で、素直にモバイルSuicaにチャージさせていただいた。

定期などは記名式のSuicaだと思うので、モバイルSuicaや定期券でSuicaをお使いの方は、Suicaポイントクラブに入って、アカウントとSuicaを結びつけておくと、意外とキャッシュバックされるかもしれない(特に、駅ナカを頻繁に使っている自覚のある人は)

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におかれましては、インデックスの存在は極めて重要だな、というわかりきったことが改めてわかった次第でございます。

«過去の 投稿