kariaの日記 @ Alice::Diary

フフーン、ノリツッコミの鳩子がはてなブログ書いちゃうよー

kariaの日記です。本家サイトはside=2です。Twitter ID:@karia
過去記事へのリンクとかは最下部参照。

自宅の大容量NAS2台をどうするんだ問題

自宅でReadyNAS Ultra6を2台運用しており、1台あたり6発のHDDが刺さるので合計12発のHDDを稼働させ続けるという異常なことをしているのですが、ReadyNAS Ultra6自体が2011年発売の代物ですでにEoLを迎えており、さすがにそろそろ寿命のことを考えてやらんとなあという時期になってまいりました。稼働開始時期を確認したところ2012年8月頃のようなので、4年以上経過していることになります。

実際のところ、過去に電源が故障してしまったこともあったのですが、その時は分解して代替のSFX電源に交換することで乗り切ってしまったのでした。ファンも一般的な12cmファンで交換可能。

IMG_5269.JPG

(ちなみに「電源の規格なんだっけ」と思ってググったら自分のFlickrアルバムが一番上に出てきてビビった)


さて今後どうするか、と考えてるのですがこれといった案がございません。とりあえず、考えている案をつらつらと書き連ねてみます。

ReadyNAS 2台分より容量が大きなストレージサーバー(またはNAS)を新設して動かす

この案には大きな問題があって、4TB以上のHDDがなかなか安くなりません。

akiba-pc.watch.impress.co.jp


3TBモデルがずーーーっと(年単位で)容量単価が最安の状態をキープしていて、例えば上記記事にある通り6000円でゲット出来たとすると1TBあたり2000円(1GBあたり約2円)です。この記事を書いている今日現在はここまで安く入手できないのですが、それでも8000円あれば十分といった状況です。比較的高めのAmazonで買ったとしても7980円といった感じ。

なので、極端な話をすると3TB HDDを大量に並べるのがストレージのコストパフォーマンスだけを見ると最高で、仮に容量が不足したら3TB HDDをひたすら追加してLVMやらなんやらで拡張していけばいくらでも追加していくことが理論上可能です。ですが、電源容量とかケースに刺さる台数とかSATAの端子数とか様々な物理的問題があるので、やっぱり無限に台数を増やし続けていくわけにはまいりません。

というか、話を戻すとやりたい事はReadyNASのリプレースなわけで、ReadyNASに刺さっている12台のHDDは既にすべて3TB以上のモデルになっています。どうせリプレースするならより大きな容量のモデルで台数の集約を図りたいのですが、4TB以上のモデルの値下がりがあまりにも緩やかすぎてコスパが悪すぎるという状況が延々続いています。一応、4TBモデルは11,000円台まで下がってきてはいるのですが、それでも3TBモデルとの価格差は歴然としています。1TBしか変わらないのになぁ。

kakaku.com

ちょっと上の6TBモデルの状況はさらに悪く、価格推移グラフを見ると11月に入ってから数千円レベルでモリモリ値上がりしている様子が観測できます。マジかよ……。まあ順当に考えて急激な円安の影響かなぁとは思いますが、それにしてもこれを数台ポンと買うぞみたいな決断はちょっと無理。

kakaku.com

というわけで大容量ストレージサーバーの構築はペンディングというか、故障交換用に必要な最低限の3TB HDDだけちまちま買い続けているといった状況です。1回真面目に試算してみてもいいけど、最低30TBは欲しいしRAID6以上の冗長性は欲しいところですね。うん、厳しい。

クラウドに頼る

これも一時期やろうとしてたのですが見事に頓挫しました。

まず容量無制限系のストレージはことごとく破滅が訪れており、代表的なものを挙げるとOneDriveが容量無制限を取りやめるという出来事が年始にありました。なので「容量無制限」をうたっているストレージサービスは基本信用しないことにしています。

いっそのことs3とかに上げちゃえばいいんじゃね、って思うんですが、さすがに月額$0.025/GBの負担は個人には大きすぎるものがあります。先ほど3TBモデルのHDDが1GBあたり約2円みたいな例を挙げましたが、これまでの運用実績を見ると短くても1.3年、長いと3.8年とか平気で持ちます。もちろんその他に電気代の出費とかもあるんだけど、さすがにバルクのHDDのほうが単価安いに決まってるわ。

あとインターネット回線の速度向上がなかなか訪れないというのも、全部クラウドに投げつける気持ちになれない大きな要素としてあります。ざっくり試算すると、1TB分のストレージを8Mbpsの速度でアップロードし続けると24.1日かかる計算になります。なぜ8Mbpsなどという大昔のADSLみたいな速度で計算しているのかというと、ISPの規制が日に日に厳しくなってきている為です。

s3の単価が今の100分の1になったりして、かつインターネット回線の速度が今の10倍ぐらい安定的に出るようになったら考えるかなぁという感じです。何年経ったらその時代来るんだろう(特に後者)。

オチ

特になく終了。可動部分(電源とファンとHDD)以外が壊れること無いだろうし、LAN内部からしか参照しないし、当面は壊れたら壊れた箇所だけ交換していけばいいか。故障してもパーツレベルで替えが効くという点では、やはりReadyNAS Ultra6はイイ奴だったなぁと改めて思ったのでした。おわり。

AndroidおサイフケータイからiPhone7への乗り換える際の各サービス対応状況簡易まとめ

iPhone7が日本国内でApple Payに対応してしばらく経ちますが、みなさんいかがお過ごしでしょうか。早速iPhone7にiDを入れてコンビニでドヤ顔しながら支払おうとしたところレジがなかなか読み取ってくれず、店員さんに「端末の先端の方が読み取りやすいですよ~」って恥ずかしいご指導を受けた方も多いのではないでしょうか。

今回iPhoneがやっとSuicaに対応したということで、元々iPhoneを使っててケースカバーあたりに入れていたカード型SuicaiPhone上のSuicaに乗り換えた方は多いかと思いますが、私のようにAndroid機を捨てたくてiPhone上のSuicaに機種変更した方はそう多くは居ないのではないでしょうか。ということで、手持ちのAndroidおサイフケータイからどこまでiPhoneへ乗換可能だったかをまとめてみました。

Apple Payで利用可

Apple Payは原則が後払い式(前払い式であるSuicaが異例の対応)なので、手持ちのおサイフケータイに載っていたサービスでApple Payになったのはたったの3サービスのみでした。

しかもSuicaに関してはビュー・エクスプレス特約非対応です。また、機種変前のAndroid端末で契約していたビュー・エクスプレス特約は機種変更を行った時点で解約となります。これはどういうことかというと、Apple Payでは東海道新幹線に乗れません

Androidおサイフケータイでは1端末でSuica入場→東海道新幹線に乗換→他地区で再度乗換……まで完結していただけに、この点は大変残念です。この制約のためにiPhoneSuicaを移行するかどうか少し迷ったレベルなのですが、よく考えてみると東海道新幹線に乗る機会は多くても年に数回の旅行の際ぐらいなので、キッパリとあきらめることにしました。

なおコールセンターの人曰く、同一のビューカードですぐにAndroidモバイルSuicaに登録しなおせばビュー・エクスプレス特約が解約されずに継続されるらしいです。うっかりiPhoneに移行してしまって後悔している出張族の方は検討してみるとよいでしょう。また、東海道新幹線に乗れる便利なICカード「EX-ICカード」を持っている人も、iPhoneSuicaとは併用できないので「IC乗車票」という名称の紙の切符を事前受取する必要があります*1。この名前、なんとかならんかったのか……。

アプリ上に表示されるバーコード提示等で代替可

ポイント関係については、普段利用頻度の高かったポイントシステムがほとんどiPhoneアプリを出しており、アプリ上のバーコードをレジで読み取ってもらうことで代替できてしまったため、おサイフケータイより若干手間は増えたもののあんまり困りませんでした。Pontaに至っては、まれに「モバイPontaFeliCa)には非対応だけどバーコードのPontaには対応」という店舗すらあって、むしろ利便性が上がったぐらいです。

ただアプリによってはちょっとした罠があって、たとえばdポイントカードは専用アプリだけでなくdカードアプリでもdポイントのバーコードが表示できたりします。ただ、dカードアプリは頻繁にログアウトが発生するのでdポイントカード専用アプリのほうが便利です。また、楽天ポイントはなぜかバーコード表示時にTouch IDを要求してきます。

代替不可

前述の通り、前払い式の電子マネーSuica以外ことごとく対応していません。まあ、実態としてSuica以外の電子マネーはほとんど使用していなかったため、残っていた小額の残高を全額使い切っておさらばすることにしました。Edyとか月単位で使ってなかったのでいい機会だったのですが、nanacoはポイント制度とも紐付いていたのでちょっと惜しい。

まとめ

Apple Payの記事のはずだったのに結論としてはバーコードの時代が到来したぞというオチでした。

ちなみに移行元のAndroid端末は、LINEのログが移せていないため結局捨てられていません。

トコトン使って売上を上げる!  LINE@活用術-1通で60万円売れる居酒屋 驚きの集客法

トコトン使って売上を上げる! LINE@活用術-1通で60万円売れる居酒屋 驚きの集客法

*1:新幹線への乗換駅で一旦iPhoneを使って在来線改札を出場し、新幹線専用改札に行ってEX-ICカードで入場し直すという手もあります。要するにEX-ICカードiPhoneSuicaを重ねて使用することが出来ません。

Ubuntu14.04でHDDが7台以上認識しない場合の対処法

ニッチすぎる記事。

HDDの容量がとにかく足らなすぎるのでRAID6のマシンでもりもりHDDを追加していったところ、7台目に差し掛かったところでどうも認識しないという症状に遭遇した。構成は以下。

「6個までしか」というところでまず思い当たったのは以下のマザーボードのスペック。

チップセット:

6 x SATA 6Gb/s対応コネクター(SATA3 0~5)を搭載し、6台の SATA 6Gb/s対応機器をサポート
RAID 0, RAID 1, RAID 5, およびRAID 10をサポート

Marvell® 88SE9172チップ:

2 x SATA 6Gb/s対応コネクター(GSATA3 6/7)と2ポートのeSATA 6Gb/s対応コネクターをバックパネルに搭載し、2台のSATA 6Gb/s対応機器をサポート
* GSATA3 6, 7コネクターとeSATAコネクターの同時使用はできません。
RAID 0 および RAID 1をサポート

チップセット側のSATAコネクタから優先して使っていたので、ちょうど6個ということは、もしかしてチップセット側のSATAコネクタしか認識しないのでは?と思って、試しにPCI Expressに刺さるタイプのSATA拡張カードを買ってみたものの、これも認識しない。

というのが昨日まで3ヶ月ぐらい悩んでいた話で、今日ふと思い立ってMarvell 88SE9172側のSATAを認識するかどうか切り分けしてみると、どうやらIntelチップセット側だろうがMarvell側だろうが、Ubuntu側で認識はしてるらしいことがわかった(6個を超えた分のどれか1つ認識しない)。起動時に一瞬エラーメッセージらしき文言が見えるけど、起動後にdmesgを漁ってみても見当たらない。これはやっかいだ……。

で、試しにHDDを1個抜いた状態で、起動中にSATAコネクタを接続するという荒技をやってみたところ、 /var/log/syslog に以下の出力があった。

Oct 30 16:29:15 yuno02 kernel: [  384.869837] ata7: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0xe frozen
Oct 30 16:29:15 yuno02 kernel: [  384.869846] ata7: irq_stat 0x80400040, connection status changed
Oct 30 16:29:15 yuno02 kernel: [  384.869852] ata7: SError: { PHYRdyChg CommWake DevExch }
Oct 30 16:29:15 yuno02 kernel: [  384.869864] ata7: hard resetting link
Oct 30 16:29:15 yuno02 kernel: [  384.878375] dmar: DRHD: handling fault status reg 2
Oct 30 16:29:15 yuno02 kernel: [  384.878389] dmar: DMAR:[DMA Write] Request device [06:00.1] fault addr fffe0000
Oct 30 16:29:15 yuno02 kernel: [  384.878389] DMAR:[fault reason 02] Present bit in context entry is clear
Oct 30 16:29:16 yuno02 kernel: [  385.615531] dmar: DRHD: handling fault status reg 2
Oct 30 16:29:16 yuno02 kernel: [  385.615545] dmar: DMAR:[DMA Write] Request device [06:00.1] fault addr fffe0000
Oct 30 16:29:16 yuno02 kernel: [  385.615545] DMAR:[fault reason 02] Present bit in context entry is clear
Oct 30 16:29:16 yuno02 kernel: [  385.762921] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Oct 30 16:29:16 yuno02 kernel: [  385.763483] dmar: DRHD: handling fault status reg 3
Oct 30 16:29:16 yuno02 kernel: [  385.763496] dmar: DMAR:[DMA Write] Request device [06:00.1] fault addr fffe0000
Oct 30 16:29:16 yuno02 kernel: [  385.763496] DMAR:[fault reason 02] Present bit in context entry is clear
Oct 30 16:29:16 yuno02 kernel: [  385.763510] ata7.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
Oct 30 16:29:21 yuno02 kernel: [  390.761108] ata7: hard resetting link
Oct 30 16:29:21 yuno02 kernel: [  390.777628] dmar: DRHD: handling fault status reg 2
Oct 30 16:29:21 yuno02 kernel: [  390.777633] dmar: DMAR:[DMA Write] Request device [06:00.1] fault addr fffe0000
Oct 30 16:29:21 yuno02 kernel: [  390.777633] DMAR:[fault reason 02] Present bit in context entry is clear
Oct 30 16:29:21 yuno02 kernel: [  391.105505] dmar: DRHD: handling fault status reg 2
Oct 30 16:29:21 yuno02 kernel: [  391.105518] dmar: DMAR:[DMA Write] Request device [06:00.1] fault addr fffe0000
Oct 30 16:29:21 yuno02 kernel: [  391.105518] DMAR:[fault reason 02] Present bit in context entry is clear
Oct 30 16:29:21 yuno02 kernel: [  391.252936] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Oct 30 16:29:21 yuno02 kernel: [  391.253477] dmar: DRHD: handling fault status reg 3
Oct 30 16:29:21 yuno02 kernel: [  391.253490] dmar: DMAR:[DMA Write] Request device [06:00.1] fault addr fffe0000
Oct 30 16:29:21 yuno02 kernel: [  391.253490] DMAR:[fault reason 02] Present bit in context entry is clear
Oct 30 16:29:21 yuno02 kernel: [  391.253513] ata7.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
Oct 30 16:29:21 yuno02 kernel: [  391.253523] ata7: limiting SATA link speed to 3.0 Gbps
Oct 30 16:29:26 yuno02 kernel: [  396.251113] ata7: hard resetting link
Oct 30 16:29:26 yuno02 kernel: [  396.267733] dmar: DRHD: handling fault status reg 2
Oct 30 16:29:26 yuno02 kernel: [  396.267744] dmar: DMAR:[DMA Write] Request device [06:00.1] fault addr fffe0000
Oct 30 16:29:26 yuno02 kernel: [  396.267744] DMAR:[fault reason 02] Present bit in context entry is clear
Oct 30 16:29:27 yuno02 kernel: [  396.595532] dmar: DRHD: handling fault status reg 2
Oct 30 16:29:27 yuno02 kernel: [  396.595545] dmar: DMAR:[DMA Write] Request device [06:00.1] fault addr fffe0000
Oct 30 16:29:27 yuno02 kernel: [  396.595545] DMAR:[fault reason 02] Present bit in context entry is clear
Oct 30 16:29:27 yuno02 kernel: [  396.742945] ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
Oct 30 16:29:27 yuno02 kernel: [  396.743485] dmar: DRHD: handling fault status reg 3
Oct 30 16:29:27 yuno02 kernel: [  396.743497] dmar: DMAR:[DMA Write] Request device [06:00.1] fault addr fffe0000
Oct 30 16:29:27 yuno02 kernel: [  396.743497] DMAR:[fault reason 02] Present bit in context entry is clear
Oct 30 16:29:27 yuno02 kernel: [  396.743522] ata7.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
Oct 30 16:29:32 yuno02 kernel: [  401.741123] ata7: hard resetting link
Oct 30 16:29:32 yuno02 kernel: [  401.757721] dmar: DRHD: handling fault status reg 2
Oct 30 16:29:32 yuno02 kernel: [  401.757725] dmar: DMAR:[DMA Write] Request device [06:00.1] fault addr fffe0000
Oct 30 16:29:32 yuno02 kernel: [  401.757725] DMAR:[fault reason 02] Present bit in context entry is clear
Oct 30 16:29:32 yuno02 kernel: [  402.085537] dmar: DRHD: handling fault status reg 2
Oct 30 16:29:32 yuno02 kernel: [  402.085550] dmar: DMAR:[DMA Write] Request device [06:00.1] fault addr fffe0000
Oct 30 16:29:32 yuno02 kernel: [  402.085550] DMAR:[fault reason 02] Present bit in context entry is clear
Oct 30 16:29:32 yuno02 kernel: [  402.232957] ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
Oct 30 16:29:32 yuno02 kernel: [  402.232978] ata7: EH complete

ん?なにこれ?と思って検索してみたところ以下のURLがヒットした。

http://dpdk.org/ml/archives/dev/2013-August/000400.html


どうやら同じエラーメッセージで悩める人がいたらしい。で、気になるのが以下の部分。

I tried that as well, but it works as if I only add intel_iommu=on.. which
means I do not receive any packets from hypervisor. I also have pci realloc
added. Does this affect?

ん、hypervisor……?

ということで、試しにUEFI (※このマザボBIOSではない) の画面からCPUのVT-d機能をOFFにして、再起動。

7台目認識した!!

なんかよくわからんけど、仮想化技術との相性が悪いらしいです。まーじかー。このマシンでKVMとか試そうかと思ってたんだけどなぁ。

そんなわけで、目下のお悩みは解決したので、これからももりもりHDD増設していく所存です。