ふらっと駅に行ってみたら、運行状況を案内するデジタルサイネージが死んでた(笑)
死んでる案内用サイネージ
ディスプレイに表示されている内容を見る限り、ああいうサイネージの画面を作ってるコンピュータは、汎用的なPCなんだなということを改めて認識、と。ま、きっとブート用のドライブが故障しちゃったのかな、と。ということは、「調整中」にはなっているけれど、オンサイトの保守待ちってことになりそうだな、と。
投稿者: 管理人 (13ページ目 (40ページ中))
NEX-5Rのバッテリーカバーを修理した。
SONYのNEX-5Rを使っているが、先日、うっかりNEX-5Rを落っことしてしまった。幸か不幸か、カメラが落下して地面とぶつかったのはレンズ部分ではなく、プラスチックのバッテリーカバー部分。しかも、本体とカバーのつなぎ目の部分が割れてしまって、カバーが本体から脱落したみたいな感じ。ま、カバーがなくてもバッテリーはツメで固定されているので、撮影できないことはないが、(割れて)とがった部分が指にあたって、なかなかドキドキする。
NEX-5Rのバッテリーカバー
これを自分で修理するといっても、もはや本体から割れてしまっているので、くっつけるのも難しいだろうと思って修理に出すしかないな、と。そういえば、ヨドバシカメラのポイント(修理などに使えるポイント)が貯まっていて修理代金に充足できそうだったので、ヨドバシカメラに修理に出すことにした。
ヨドバシカメラもどこか修理を担当する会社に委託しているらしく、修理の見積もりができたら、そこから電話がかかってくることになっていると告げられた。…で、数日くらいしたら電話がかかってきて見積もりを教えて貰った。バッテリ-カバーの取り替えで、ざっくり7000円ほど(正確な金額を聞いたけど忘れた)と言われた。ま、他にどうしようもないので、素直に発注することにした。
あと、ついでにコンデジのDSC-WX200(いわゆるサイバーショット)のコネクタカバーのツメが割れて閉められなくなっていたので、それも見積もりをもらっていたけれど、こっちは4,000円ちょっと(これまた正確な金額を忘れた)とのことだった。WX200は、本体の値段が2万円していないのに、コネクタカバーの修理に4,000円はなかなか切ないので、修理を断念した。
修理に出してから修理完了まで2週間くらいはかかったけど、無事に修理されて帰ってきて一安心。
どうやら、さくらインターネットがVPSサービスをリニューアルするらしい。
さくらインターネット、「さくらのVPS」のサービスリニューアルを実施：
http://www.sakura.ad.jp/press/2014/1120_vpsupdate/
インターネットデータセンター事業を運営するさくらインターネット株式会社（本社：大阪市中央区、代表取締役社長：田中 邦裕）は、I/O性能に優れたSSDを手軽な価格で利用できる仮想サーバサービス「さくらのVPS」のサービスをリニューアルし、2014年11月27日より提供開始いたします。また、コントロールパネルもより使いやすく一新いたします。
ま、スペックとか価格体系をざっくりと拝見する限りでは、LinodeやDigitalOceanを強く意識したんだろうなぁ。
特にLinodeは、日本、しかも東京のKDDIのデータセンターにロケーションを持っているっぽいので、英語の管理画面がなんとか使いこなせたら、さくらインターネットのVPSよりもLinodeの方がかなりコストパフォーマンス的には優れているという印象ではあったが、さすがに追随してきたようだ。そもそも、さくらインターネットみたくクラウドの基盤を構築していれば、クラウドサービスから柔軟性を取っ払って値段を下げればVPSサービスは提供できそうな(かなり雑な妄想だが)気がするので、価格での競争においては、やっぱり抱えているサーバの数の勝負に収斂していきそうな気がする。
しかし、さくらインターネットのニュースリリース、価格とスペックに終始していて、ロケーションについて言及していないのはちょっと気になった。当然、石狩では提供するんだろうけど、東京や大阪のロケーションは相変わらず選択できるんだろうか。
docomo wifiが使えるカフェにやってきてみた。スマホのSIM認証で0001docomoってSSIDには接続できているが、MacBook Airで0000docomoに接続しようとすると、WiFi自体の認証は通るがIPアドレスが振られない。どうやら、DHCPサーバがダウンしているか、輻輳状態にあるらしい。
ただ、SSIDがちょっと違うだけで接続しているAPは物理的には同じだろうと思うが、0000docomoだけDHCPサーバが応答しないっても、なかなか切ない。もし、どこかからWiFi APの不具合を報告したら、リモートでAPをリブートしてくれるとか、そういう便利なフォームがないかと思ったが、見当たらず…。DHCPでIPアドレスが振られないとなると、どうしようもないしなぁ…地味に困った。ま、スマホのテザリング使えばいいんだけど、比較的大きな画像のアップロードやダウンロードをしなきゃならんので、かなか切ないしなぁ。
とある共用型のレンタルサーバを使ってWordPressを構築することになったので、そのレンタルサーバが提供しているSSHでログインしてみた。
そしたら、(必要もなさそうだけど)dmesgが解放されてて、うっかり叩いてみたら、DellのRAIDカード(とはいえ、中身はLSIのMegaRAIDなんだけど)がちらっと見えた。
megasas: max_sectors : 0x230, cmd_per_lun : 0x100
scsi0 : LSI SAS based MegaRAID driver
Vendor: DELL Model: PERC H710 Rev: 3.13
Type: Direct-Access ANSI SCSI revision: 05
Vendor: DELL Model: PERC H710 Rev: 3.13
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 3904897024 512-byte hdwr sectors (1999307 MB)
sda: Write Protect is off
sda: Mode Sense: 1f 00 00 08
SCSI device sda: drive cache: write back
SCSI device sda: 3904897024 512-byte hdwr sectors (1999307 MB)
sda: Write Protect is off
sda: Mode Sense: 1f 00 00 08
SCSI device sda: drive cache: write back
ふむ、このレンタルサーバではDell製のサーバを使っているのかぁと思いながら、刺さってるのは少なくとも2TBのHDDが2本っぽい。…ってことはRAID1で運用しているのだろうか。
そういえば、他の某レンタルサーバでもRAID1を使っているっぽいって話を見かけたなぁ。最近のHDDはとにかく大容量化が進んでいるので、1台のサーバーにそんなに数多くのHDDを刺さなくてもRAID1でそれなりに大容量のストレージを積めるようになったってのは大きいかもなぁ…。ま、多くのユーザーはWebサーバにHTMLやjpegくらいしか置かないだろうから、ユーザーに提供するストレージ分だけストレージを積んでおく必要もないだろうし(仮に1ユーザーに10GBを提供して、1台のサーバに100ユーザー収納したからといって、そのサーバに1TBのストレージを用意してないとまずいかというと、そういう感じでもないだろうし)
…と、なんとなく見えたスペックを元にDellのサイトで見積もりを作ってみたら、フツーにDellから買うと、だいたい1台あたり60万円くらい、サポートも買って70万円を超えるくらいのサーバーかなぁって印象だった。ま、高くもなく安くもなく、よく売れてそうなサーバーって感じだろうか。
そろそろ、ElasitCacheのredisサーバをセットアップしようと思って、AWSのWebコンソールを開いた。そんなに大規模なキャッシュとして使うわけでもないので、t2.microインスタンスくらいでいいかなぁと思ったら、multi-AZのチェックボックスを入れるとt2インスタンスが候補から消えるという…(汗)
さすがに、Webコンソールのバグではないだろうと言うことで、調べてみたら、AWSブログにしっかり書いてあった。
【AWS発表】ElastiCacheでもT2インスタンスタイプを利用可能に：
T2インスタンスはAmazon Virtual Private Cloud内でのみサポートされています。 Redisのバックアップおよびリストア機能とRedis AOFは現在のところT2インスタンスではご利用いただけません。 通常の方法(コマンドライン、API、CloudFormation、コンソール)で起動することが出来ます。
おっと、マジかー(汗)
しかし、t2インスタンスがMulti-AZ(「バックアップおよびリストア機能」とMulti-AZは同じ意味なんだろうか…)とかAOFが使えないのって、t2インスタンスがephemeralディスクを持っていないこと(m1インスタンスとかって、HDDだけど、一応、ephemeralディスクを持ってるし)と関係があるのかなぁ…と妄想してみる。リカバリーする際にephemeralディスクを使ったりするんじゃないだろうか。もしそうだとすると、t2インスタンスでこれらの機能を使おうとすると、一時的にしろEBSをアタッチするなんて方式で実現するしかなさそうなので、なかなか大変そうなわけで、そうなると「現在のところ」ってのは割と長い時間に渡ってこのままなんじゃないかという気もするな。
さて、Single-AZでt2インスタンスを使うか、Multi-AZでm1インスタンス使うか…ケチケチで構築しようとすると、なかなか微妙な選択肢を迫られるなぁ…いやはや。
なんかサンディスクが512GBの容量のSDカードを発売することになったらしい。
サンディスクは10月17日、世界最大容量となるSD／SDXCカード「サンディスク エクストリーム プロ SDXC UHS-Iカード 512GB」を発表した。12月より出荷する。
12月に発売なのでもう少し先の話にはなるけれど、512GBか…。普通にSSDとかHDDのサイズだもんなぁ。かなり驚いてしまうくらいの大容量だなぁと思うのが正直なところ。フラッシュメモリの高集積化ってどこまで進むんだろう。
ただまぁ、一方で、SDカードに入れといて消えられたら切なくなるしかないデータ容量なわけで、なんとなくSDカードの中身をいい感じに保護するソリューションとセットにでもしないとなかなか使いづらいんじゃないかなぁと思う次第ではある。
いやはや、私のような庶民には、64GBくらいのサイズのSDカードがコストパフォーマンス的にも合っているし、適切にバックアップが取れそうな気がしないでもない。
KindleのPaperWhiteを使っているが、最近、めっきりバッテリーの減りが早くなってしまった。いや、早くなったどころの騒ぎではなく、満充電してあったはずなのに1日も経過しないうちにバッテリーのインジケータが残念なくらいにゼロに近づいてしまっていた。
最初は、そろそろ壊れたかなぁと思ったけれど、一応調べてみると、なんとなく何が起こったかわかったような気がする。
自炊したPDFをKindleで読もうと思って、KindleをWindowsマシンにUSBケーブルでつないでPDFをコピーしたのが原因っぽい。しかも、そのPDFは、Calibreで極めて雑に作ったPDFであった(汗)
推測ではあるが、Kindleはストレージに置かれたファイルをドキュメント一覧に並べるべく中身を解析しているインデクサのようなプロセスが動いているのではないだろうか。今回、私がKindle PaperwhiteにコピーしたPDFをインデクサが解析できなくて、ずっと延々と読み続けていたんだろう。そして、バッテリーの残量が少ない時にはインデクサが停止するような保護機能があったから、めちゃくちゃ早くバッテリーが減るけれどバッテリー切れにはなっていないという事態になったのではないかと思う。
ま、雑に作ったPDFをKindleから削除してしまえば、きっと解消するんだろうなと思ったけど、そろそろ既読のドキュメントも溜まっていたので、一旦、Kindleをリセットしてまだ読んでない本をAmazonのクラウドからダウンロードすることにした。リセットしたせいか、問題のPDFが消えたせいか、判然とはしないものの、とりあえずバッテリーがすごい勢いで減るという事態は解消できている。
昨日の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なんかもそこに含まれるだろうから、影響の実態はよくわからないけど、ぱっと見た感じでは結構広範囲なんだなという印象。ま、あとは、そういう広範囲に影響のあるルーターが冗長化されてないのかとも思ったけど、フェイルオーバーに失敗したんだろうか。ま、回復したからいいんだけど。
ちょっと公衆無線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は少なくなるもんなぁ…。なんかこう、電波行政の観点から、こういう状況になる前になんとかできなかったんだろうかとは思うけども…いやはや。