裸族の集合住宅5Bayが安定しなくて苦しんだ録画サーバの構築

自宅で録画サーバを設置して楽しもうとおもっていろいろ試行錯誤をしたメモです。

とりあえず、ざっと録画サーバの構成としては、基本的にCentOSで、ディスクをLVMで束ねて、まずはMPEG2-TSで保存されたものを順次、H.264/AACなMP4としてトランスコードします。再生に関しては、HTTP-LSでのリアルタイム視聴か、HTTP経由(videoタグつかって適当にプレーヤーをブラウザで)の再生、samba経由での再生の3パターンの手段を使うような感じになっています。

で、問題はこの録画サーバのディスク部分。当初は、裸族の集合住宅5BayをeSATAで接続した上で、LVMで束ねて、一部をシステム領域として、CentOSのアレコレを入れるとして切り出しつつ、残りを録画されたファイルを保存するようなディレクトリとしてマウントしていました。で、実際、まずはセットアップで、ポートマルチプライヤ対応なんて当然マザーボードのSATAは使えないのにすっかり抜けてて、慌てて適当にPCIeなSATAのカードを安いのを買ったのですが、何故かカード挿すだけで電源が入らなくなるという切ない現象にあって、玄人志向のSATA3E2-PCIeに変更してそっちだと何故か認識したということもありました。が、まあまあ、とりあえず、録画からトランスコードまでが動作するようになりました。

それで、2週間ほど運用していたのですが、なんかたまにディスクを見失うという怪現象に見舞われるようになりました。syslog見てる限りだと、hardware resettingと出て、そのままディスク自体がいなくなったことになっています。そして、ハードウェア的には、なぜか一番上のHDDだけLEDが点いていて、それ以外のHDDのLEDは消灯しています。そうすると、LVMで束ねているわけで、SSHでのログインすらできなくなります。んで、linux側から認識しなおさないかなーとおもって、無理矢理bash使えるようにして、rmmod, insmodとかSATA関係のをやってみたんだけど、そういうので復活する気配もありません(そういうことをするのにも、シリアルコンソールを有効にしてなかったのでまずそれを有効にしつつ、ほかのマシンから入れるようにみたいなめんどくさいこともしました。)そうすると、再起動するしかなくて、でも、SSHで入ったりもできないので、再起動は割と面倒です。とりあえず、すでにブラウザから再起動できるようにとかには改造していたわけですが、結局そもそもApacheさんも死亡している状況になるのでそれも使えません。

その後、USB3.0に接続を変えてみたりもしたのですが、むしろディスクを見失う率は上がったかにみえる程度でダメな感じです。BIOSの設定やら、eSATAのカード変えてみたりとか試行錯誤したのですが、結局、解決策を見いだすことはできませんでした。検索してみると、同様の症状の人もいるようなのですが、決定的な対策はなさそうということで諦めました。

というわけで、次は他のマシンに接続を試しました。こちらはDQ45CBという割と古いIntelのマザーボードにCore2Duo E7500というCPUで今となってはあまりパワーのあるマシンではありません。基本的にこっちは自宅用NASとして動作させていて、Gentooがインストールされています。こっちにeSATAのカードごと移して同様にLVMで束ねてみました。それで、とりあえず、録画ファイルではなく、定期的に適当なファイルを置いたり消したりを繰り返してみたところ、なんということでしょう、全くもって安定しています。何故なんですかね、いろいろ腑に落ちません。。。カーネルのバージョンとか、なんかのハードウェアの相性なんでしょうか、解せません。

とはいえ、こっちなら安定しているということで、このディスクをネットワーク越しにマウントする運用を思いつきました。とりあえず、NFSかなーとおもいつつ、セットアップがめんどくさかったので、sambaで録画サーバからマウントして録画とトランスコードの保存領域として設定してみました。そうすると、ディスクを見失うようなことはなくなり、ディスク見失う問題に関しては解決し、快適録画ライフが訪れたように思っていた時期もありました。

ちょっと運用してみてすぐ気づいたのですが、ネットワーク越しにマウントすると、どうもトランスコード後のMP4で音ズレやらエンコード失敗が頻発します。どうもTS時点では正しくファイルが書かれているようなので、問題はffmpegでの読み書きのときのようです。ざっとググったりしながら挙動を確認したところ、ffmpegさんはts読み込んでトランスコードする場合、そのエンコードに必要なパケットの読み込みが間に合わなかったときに割とさくっと諦めて飛ばしてしまうようです。それで、エンコード失敗しまくってダメなMP4ができてしまうようです。オプションで調整できないかも試行錯誤してみたんですが、どうしても音ズレが解決できませんでした。これはもっと頑張ればどうにか解決できそうな気がしましたが、まあ、そもそも、ffmpegでトランスコードするときとかみたいに細切れで読み書きするのにsambaなのもどうなのよ、という気がしてきました。

で、結局ということで、やっと現状の運用状況について、結局、単一の4TBのディスクだけを録画サーバに挿しています。そして、そこにTSの録画からトランスコードまでをローカルで完結して行うようにしています。ただ、4TBくらいしかないと、TSを保存しておくような運用をしてしまうと割とさくっと領域が足りなくなるというのと、せっかくかった裸族の集合住宅がまったく利用できないのも悲しすぎるため、ということで、見終わったけど消すわけではないファイルに関してはブラウザ経由でフラグを立て、それに関しては、定期的なrsyncで拾って裸族が接続されているNASにコピーするという運用に落ち着きました。ついでなので、自宅NASの他のディスクたちと同様にrdiff-backupによって増分バックアップされるようにもしたので、HDDのクラッシュに対する対策はこれでいいかなーという感じにしています。(ちなみに、最終的にはBitcasaにもコピーしてる。)

今回の教訓というかメモ

  1. 裸族の集合住宅5Bayはオススメしない。安さよりは安定性を選ぶ方がなにかと幸せになれますね。まともなやつを買いましょう。
  2. ffmpegのトランスコードはIn/Outともそれなりにレイテンシが悪くないデバイスから読み込むべし、なんだろう、たぶん。ちゃんと調べる時間をいつか取りたい。
  3. 最近、自宅サーバはLVM+RAID6からLVM+rdiff-backupに移行して、クラッシュしたらまっさらにしてバックアップから戻すという運用に変えたけど、RAID再構築に比べても、リビルドの手順とか深く考えなくてよいというところで割と楽なのでオススメというのも、ちゃんと詳細をメモしておきたいところ。Bitcasaへのコピーもあるので最悪の場合は時間がかかるけど、という保険があるのもポイントかな。
  4. トランスコード時に、8コアが全部ぶん回ると、ものすごい熱でファンが全開になってすごい音が発生するのが今の悩みどころ。CPUファンをもうすこしまともで静穏な他のものに変えるべきか。

という、箇条書きにしては長いメモを残しつつ、まあ、そんなこんなで最近は結構テレビを見るようになって、仕事中なんかにBGM代わりにいろいろ見るようになりました。割と幸せ。