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

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

Kindle Paper Whiteのバッテリーの減りが早くなった

KindleのPaperWhiteを使っているが、最近、めっきりバッテリーの減りが早くなってしまった。いや、早くなったどころの騒ぎではなく、満充電してあったはずなのに1日も経過しないうちにバッテリーのインジケータが残念なくらいにゼロに近づいてしまっていた。

最初は、そろそろ壊れたかなぁと思ったけれど、一応調べてみると、なんとなく何が起こったかわかったような気がする。

自炊したPDFをKindleで読もうと思って、KindleをWindowsマシンにUSBケーブルでつないでPDFをコピーしたのが原因っぽい。しかも、そのPDFは、Calibreで極めて雑に作ったPDFであった(汗)

推測ではあるが、Kindleはストレージに置かれたファイルをドキュメント一覧に並べるべく中身を解析しているインデクサのようなプロセスが動いているのではないだろうか。今回、私がKindle PaperwhiteにコピーしたPDFをインデクサが解析できなくて、ずっと延々と読み続けていたんだろう。そして、バッテリーの残量が少ない時にはインデクサが停止するような保護機能があったから、めちゃくちゃ早くバッテリーが減るけれどバッテリー切れにはなっていないという事態になったのではないかと思う。

ま、雑に作ったPDFをKindleから削除してしまえば、きっと解消するんだろうなと思ったけど、そろそろ既読のドキュメントも溜まっていたので、一旦、Kindleをリセットしてまだ読んでない本をAmazonのクラウドからダウンロードすることにした。リセットしたせいか、問題のPDFが消えたせいか、判然とはしないものの、とりあえずバッテリーがすごい勢いで減るという事態は解消できている。

さくらのVPSが広範囲に障害を起こしてたっぽく

昨日の22時半頃、サーバを監視しているZabbixからメッセージが届いた。使っている、さくらインターネットのVPS2台が通信不能になっているらしい。ちょうど帰宅途中で手が出なかったので、しばらく電車に乗ったままでぼーっとしてたら、23時頃にまたZabbixから、回復を伝えるメッセージが届いた。

まぁ、何台もVPSを使っているとこんなこともあるよねぇ…と思ってたら、さくらインターネットのサポートページに障害のお知らせが出てた。

さくらのVPS(石狩リージョン) 障 害 発 生 の お 知 ら せより

発生日時 : 2014年10月10日22時40分~2014年10月10日22時59分

障害内容 : 収容ルータの動作不具合のため正常な通信が出来ない状態が発生いたしました。

影響範囲 : さくらのVPS 石狩リージョンにおけるIPアドレスが下記の範囲のお客様

で、下に68行にわたってずらっとIPアドレスが並んでいるんだけど、1行あたり255個のアドレスだから、ざっと17,300台分のIPアドレスが影響範囲に入っていることになる。もちろん、契約されていないVPSなんかもそこに含まれるだろうから、影響の実態はよくわからないけど、ぱっと見た感じでは結構広範囲なんだなという印象。ま、あとは、そういう広範囲に影響のあるルーターが冗長化されてないのかとも思ったけど、フェイルオーバーに失敗したんだろうか。ま、回復したからいいんだけど。

au Wi-Fi SPOTの裏側はWiMAXとのこと。

ちょっと公衆無線LANについて調べ物をしてて、「au Wi-Fi SPOT」のWikipediaのページを見てたら、こんなことを書いてあるのを見つけた。

au Wi-Fi SPOTではバックボーンにUQコミュニケーションズの展開するモバイルWiMAX回線を主に利用しているため、WiMAX回線の混雑具合によっては通信速度が低下する場合がある。KDDIでは品質の低下しているスポットを光ファイバー回線へ切り替える事で品質低下を防ぐ予定である。

au Wi-Fi SPOTは、バックエンドにWiMAXを使ってるのか…。無線LANの上流回線が無線なのね。そういうことならば、au Wi-Fi SPOTにつないだけど帯域幅が確保できないとか、LTEで繋いだ方が速いみたいなことも起こりえるだろうなぁ。ソフトバンクのBBモバイルスポットは、昔ながらのADSLで繋がってるっぽいし…。データ転送量で課金されない(正確にはデータ通信量の制限がなさそうな)ことは魅力だけど、上流回線を眺める限りは帯域幅は確保しづらいのかもしれない。一応、DoCoMo WiFiなんかはNTT-BPが運営しているAPだから、NTT東西のフレッツに接続されているっぽいから上流回線の帯域幅は、他社に比べて安定的に確保できてそうな雰囲気はあるかな、と。

ただし、街中だと、乱立する公衆無線LANのAP同士、それに加えて、WiFiルーターが干渉してるって問題があるので、公衆無線LANの上流回線の問題ってのはそう大きなインパクトを与えないかもしれない。そして、田舎に行ったら行ったで、公衆無線LANのAPは少なくなるもんなぁ…。なんかこう、電波行政の観点から、こういう状況になる前になんとかできなかったんだろうかとは思うけども…いやはや。

さくらインターネットに東京リージョン

…いや、実にどうでもいいことなんだけど、さくらインターネットのWebを見てたら、こんなニュースリリースが出てまして。

さくらインターネット、「さくらの専用サーバ」東京リージョン提供開始

インターネットデータセンター事業を運営するさくらインターネット株式会社(本社:大阪市中央区、代表取締役社長:田中 邦裕)は、2014年10月1日より、最速10分納品の高性能専用サーバサービス「さくらの専用サーバ」において、東京リージョンの提供を開始いたします。

「リージョン」というのは、AWSやニフティクラウドみたいなクラウドベンダーがデーターセンターの所在地をもやっとさせつつも、この辺ってことを示すために使われている便利なキーワードであるような気がしてて、どうもクラウドベンダーが使いがちなワードかなぁとも思うわけです。

そんなわけで、さくらインターネットがニュースリリースで「東京リージョン」というキーワードを使っていたので、うっかりと、”さくらのクラウド”もとうとう東京進出かーと思っていたら、従来型の専用サーバのサービスを「東京リージョン」で提供するってニュースらしく。まぁ、シンプルな勘違いってコトでごめんなさいってことではあるんですけど、さくらのクラウドも石狩以外のリージョンで提供しないのかなぁと楽しみにしていることではあるんですが…いやはや。

DellのVenue8では、Chromeが遅いらしい(体感値…汗)

社内でDellのAndroidタブレット「Venue8」を使っている人がいたのだが、どうやら、GoogleのChromeの動きがモタモタするらしい。ちょっと触ってみたが、タブの切り替えや、別アプリを起動している状態からChromeへの復帰とかのシーンで、なんか頑張ってそうだけど画面的には動きがなくて残念な状況になってしまう。

で、どうしたもんだかと相談されたので、すんなりとChromeはそのうちアップデートが行われるでしょうけど、それまでは特に手の打ちようもないので、素直にFirefoxにしましょうということで、GooglePlayからFirefoxをダウンロードしてインストールしてあげたら、(Chrome比で)かなり快調に動くようになったそうだ。

…しかし、手持ちのARMなAndroid端末(各種、Snapdragonとか、Exynosとか)では、Chromeがそんなにもたつくような状況は起こらないので、x86なAndroidならでは(DellのVenue8はIntel Atom搭載)の症状だろうか。まぁVenue8は1GBしかメモリを積んでいないので、そのせいかもしれないけど…でも、めちゃくちゃメモリが少ないって感じでもないけどなぁ。。。そういえば、Dellだけでなく、Asusあたりも7インチや8インチあたりのタブレットにAtomを搭載しているので、Asusのプロダクトでも同様の症状が起こるのか気にならないでもないけれど手許にない(汗)

…DellのFirmware(素のkitkatにDellが味付けしたもの)のせいだとすると…これは切ない事象かもしれない(遠い目)

AWSの「秋のEC2再起動祭り」の背景はXenの脆弱性対応らしい

先日から、EC2のインスタンスの再起動祭りが行われていて、きっとアレはXenのパッチに伴う再起動だろうと言われていたが、やはり、Xenの脆弱性対応だったらしい。

EC2メンテナンスについての続報@Amazon Web Services ブログより

本日は先週末(2014/9/27から)に実施した、再起動を伴うEC2のメンテナンスについての続報や背景をお知らせします。

これはXen Security Advisory (XSA­108)に関する全てのセキュリティリスクから皆様を守るために実施され、AWSは昨日(米国時間9/30)遅くすべての対象EC2(全体の10%未満)のメンテナンス作業を完了しました。

で、今回の再起動祭りの原因となった脆弱性についてはこちらに情報があったけど、何を書いてるのかまったくわからないので、今回の脆弱性に関するニュース記事を眺めてみた。

The Xen Vulnerability That Rebooted the Public Cloud@eWeekより

The impact of the flaw is that an attacker could potentially crash the underlying host server and potentially read data from other virtual machines on the system. So, the problem for public cloud providers, for example, is that the flaw could have enabled an attacker to potentially get access to other resources and data on the cloud. Needless to say, that would have been catastrophic for any public cloud provider, especially the world’s largest.

適当に訳してみると、「今回修正されたXenの脆弱性を突くことによって、物理サーバーをクラッシュさせたり、他の仮想サーバ(適当な訳注:きっと同じ物理サーバの上で動いてる仮想サーバだろうな)のデータを読んだりすることが、潜在的にできるようになってしまう。

パブリッククラウドにおいては、攻撃者がクラウド上の他人のリソースやデータにアクセスできることになってしまう。パブリッククラウドを提供する事業者、特に世界最大級の事業者にとっては、壊滅的な事態に陥ってしまうことは言うまでもない」…って感じだろうか(誤訳してたらごめんなさい)

ただまぁ、今回の脆弱性はIntelのVT-xやAMD-Vを使った、HVM (Hardware-assited VM:ハードウェア支援仮想化。完全仮想化とか言われてる方式か)で仮想化されたサーバにのみ影響があるようで、従来のPV(ParaVirtualisation:準仮想化)では影響を受けないらしい。

再起動祭りをやったのはAWSだけかと思いきや、個人的には縁のないRackspaceやIBM Softlayerあたりも再起動祭りをやってたらしい。いやはや、ハイパーバイザのバグとなるとさすがに影響が大きいな。

追記:そういえば、LinodeってXenを使ってたような気がするんだけど、どうなったんだろう(遠い目)

HDDの故障率とか

Gigazineが「HDD約3万5000台を運用した実績からSeagate製品の圧倒的壊れっぷりが明らかに」って記事で紹介してたのが、Backblazeというオンラインストレージ屋さんのブログ。で、そのエントリーのタイトルは「Hard Drive Reliability Update – Sep 2014」。

HDDベンダーごとに故障率を出している、インフォグラフィックスが掲載されていた。…ご丁寧に、このタグで、このイメージをシェアできるよって書いてあったので、素直に貼るとこんな感じ。

Hard Drive Failure Rates by Model

いやー、Seagateさんの故障率の高さが目立つなぁという感じですが、Seagateといえば、ファームウェアのバグの問題が世間を賑わせたわけですが、その頃のモデル(Barracuda.11シリーズ)を使ってたら故障率は高いだろうと思って調べてみたら、SeagateのラインナップのBarracuda.12シリーズでも故障率高いから、うーんという感じ。

じゃぁ、BackblazeはSeagateだけ数多く使っててHGSTとか数が少なければ、故障率も正しくは出てこないよね!と思ったら、別の記事「What Hard Drive Should I Buy?」によれば、Backblazeで使っているHDDはSeagateとHitachiでそれぞれ12,000台ずつって感じだから、特にSeageteが数多いわけでも、HGSTが少ないわけでもないらしい。

で、この1月の記事では、こんな結論を出している。

We are focusing on 4TB drives for new pods. For these, our current favorite is the Seagate Desktop HDD.15 (ST4000DM000). We’ll have to keep an eye on them, though. Historically, Seagate drives have performed well at first, and then had higher failure rates later.

Our other favorite is the Western Digital 3TB Red (WD30EFRX).

まぁ、WesternDigitalのRedシリーズも使うけど、Seagateも長く使うと故障率上がるものの、最初は性能いいしなぁということらしい。RAID等で保護されていれば故障した際にはHDD交換すれば済むけど、堅牢だけど、遅いHDDを並べても性能がでるわけでもないしなぁ。

そんなHGSTの3.5インチHDD事業は東芝に買収されたことを思い出すと、Toshibaの故障率の推移はどうなっていくのか、ちょっと興味深い。今後もbackblazeにはHDDの故障レポートを公開して欲しいな、と。

Amazon Cloud Driveのデスクトップアプリがなくなった。

ちょうど一年前くらいに「Amazon Cloud Driveが直らない…」って記事を書いて、Amazon Cloud Driveのデスクトップアプリを改善して欲しいなぁ…なんてことを書いて、しばらくほったらかしにしてて、ふと新しいバージョン出てるかなと思って調べてみたら、こうなっていた。

Cloud Driveデスクトップアプリについて

Cloud DriveデスクトップアプリをAmazon.co.jpからインストールすることはできなくなりました。すでにコンピュータへインストールされている場合は、引き続き、ファイル、写真およびビデオをCloud Driveにアップロードできます。Cloud Driveデスクトップアプリをアンインストールすると、再度インストールすることはできません。ウェブサイト上のCloud Driveで、ファイル、写真およびビデオをアップロードしてください。

まぁ、ブラウザを使ってアップロードできるんだから、そっちでやってくれということか。まぁ、最近、Webサイトもリニューアルしたみたいだしな。Amazonとしては、Webサイトに訪問してもらって、うっかりついで買いしてもらった方がメリットあるだろうし。

というわけで、まともに動かなかったAmazon Cloud Driveのデスクトップアプリはアンインストールすることになるだろうなぁと…。

LGのG2のカメラ

ドコモがオンラインショップで叩き売りしてたLGのG2…ドコモの型番だとL-01Fなんだけど、このカメラアプリがちょっとなぁ。

まぁ、夏の暑い日にズボンのポケット入れたまま歩いて、ポケットから引っ張り出して写真を撮ろうとしたら「高熱のためカメラが起動できません」みたいなメッセージが出てきてカメラが使えないのは120歩譲って許す(とはいえ、XperiaでもGalaxyでも、似たようなことしてたはずだけど、そんなメッセージを見たこともなければ、壊れたこともないんだけど、まぁ、保護機能だから壊れてからじゃ遅いと言われりゃ、そのとおり)

普通にカメラアプリで写真を撮って、カメラアプリ内のサムネイルまで作成されるのに、後から、その写真を探しても記録されてないってのは何とかならないのかなぁ…。

ふと、可能性として思いついたのは…。高解像度で撮って、さっさとカメラアプリを閉じちゃうから、写真データをストレージに書き込んでるうちに、アプリが落ちちゃってるのかもしれないけど、もしそうなら、それってどうにかなんないのかな(汗)

…とりあえず、切り分けか…

追記:
やはり、カメラアプリからストレージに写真が記録されなくなってしまうと、再起動かけないと記録できる状態に戻らないような雰囲気。そして、再起動かけると、撮った後、ぱぱっとカメラアプリからホームに戻っても写真は記録されてた。もしかすると、メインメモリの空き状況の影響とかあるんだろうか。うーむ

LinodeとかDigitalOceanとか。

Linodeのリージョンが東京にあることに気づいて、早速、アカウント作ってインスタンスを立ててみた。

Linode TokyoはどうやらKDDIのデータセンターにあるらしく、同じくKDDI系のCloud Coreのインスタンスにping打ってみたら2msくらいで返ってきた(笑)あと、千葉のフレッツ網からのpingも20msくらいでネットワーク的にはかなり快適。DigitalOceanの西海岸だと太平洋越えで100ms超えるし、同じくDigitalOceanのシンガポールも100ms超えてたことを考えると意外と悪くないかも。メモリーは1GBしかないけど、ストレージはSSDだし。

しかしまぁ、AWSとかGoogleのクラウドが細かくネットワークセキュリティに配慮した仕組みを備えている一方、LinodeやDigitalOceanみたいな、安い系のVPS屋さんの「細かいことは気にしない」系のインスタンスは、何個もインスタンスたてると大変かも知れないけど、ちょっと1小インスタンス立ててWordPressでも運用してみようかなみたいな用途には悪くないかもしれない。とりあえずVPCみたいな仕組みは大掛かり過ぎるし、インスタンスでiptablesも使えるわけだし。

インスタンスが起動したら、とりあえずsshでルートログインさせる(rootパスワードを起動時にwebから入力させるのがLinodeで、DigitalOceanはメールで送られてくるんだったか)感じはなかなかドキドキしないでもないけど。

もし、初期ログインの後、ユーザーが適切に設定を変えられるのであれば、最初の導入時だけ雑なる感じになってしまうのもしょうがない…のかな(遠い目)

« Older posts Newer posts »