ただのにっき。

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

23ページ目 (40ページ中)

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

はてなで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を接続して、同時並行でテストするしかないかと…。

«過去の 投稿 新しい 投稿 »