2020年08月11日(火) - 22:21 | カテゴリ:
Linux
数ヶ月前に実施した自宅サーバ刷新に合わせて、録画サーバ構成も大きく見直した。
従来はチューナーにPT2を使っており、必然的にPCIスロッド搭載の自作PCが必須だったが、
今回はUSB接続のPLEXチューナーに変更したので、大きな設備を用いる必要がなくなった。
また、本格的な仮想サーバ基盤をさくらの専用サーバに移設した事もあり、
録画サーバだけの為に場所を取りたく無かった。
また、現行世代のパーツでPCを組もうにも、
PCIスロッドを搭載したマザーボードが皆無なのでパーツ入手性も考慮すると諦める必要があった。
今回は録画サーバの構成紹介であって、
地デジを復号・録画する様な物じゃないのであしからず。
構成は至ってシンプル。母体となるベアボーンPCにPLEXチューナーを接続した。
ベアボーンPCには、ASRock DeskMini A300・ASRock DeskMini 310をチョイス。
筐体が小さくて置き場に困らないのと、デスクトップ用CPUを搭載出来る上、
2.5インチベイが2個あるのが決め手となった。

メイン機(左)は、以前から気になり少しずつ使っていた「foltia ANIME LOCKER」を導入。
サブ機(右)は、従来通りにCentOSを使った独自構成となり、今風のアプリケーションで組んだ。
WebサーバはNginxを使っても良かったのだが、使い慣れていないNginxを使うのも怖かったので、
一番慣れているapacheを採用した。
OS・データ領域はフルSSDにしつつ、録画データ領域はRAID1を組んで冗長化も行った。
ただ、foltiaについてはOSインストール先をRAID1にするのが面倒だった為、
OS専用にM.2-SATAのSSDを積んでシングル構成にした。
foltiaは仮想アプライアンスの様な物なので、
最悪OSが吹っ飛んでも録画データさえ生きていれば再インストールで乗り切れると割り切った。
………
問題だったのは、チューナーフル稼働時にPX-Q3U4の排熱ファン回転だった。
PX-Q3U4はフル稼働した時にチップを冷却する為にファンが搭載されているのだが、
このファンが小口径で相応の回転速度を持っており、
回転振動がチューナーに悪さをしてしまいドロップが発生する様になる。
ドライバをサードパーティの物にするとある程度安定する様になるのだが、
今回は排熱ファンを取り外して物理的に振動を起きなくさせた。
また、ファンを取り外した分を効率的に排熱させる必要があるので、
側面に排熱穴を開けつつチューナーを縦置きする事で対処した。
という事で、改造したPX-Q3U4を使いつつこんな環境で稼働させている。

撮影場所が暗かったので、フラッシュを焚いたら左のファンフィルターが凄い事に (;´Д`)
実際は埃の堆積もほぼ無い。
この状態で3ヶ月以上稼働させているが、独自構築した録画サーバで問題は発生していない。
むしろ、foltiaの方で稀にチューナーを認識しないケースが出ており、
何処かでOS入れ替えかチューナー変更が必要になりそうだった。
今回構築した環境のメリットはなんと言っても小型な所。その上、チューナーが入手しやすいのも追加点となる。
USB接続チューナーは種類が増えてきており、以前話題になったフリ○オもUSB対応の新バージョンが出るらしい。
来年には活躍しそうなサーバなので、今後も上手く運用していきたいと思う。
« 続きを隠す
2020年07月04日(土) - 23:02 | カテゴリ:
Linux
前回書いた通り、DNSSEC検証用にドメインを取ったので処理する権威DNSが必要になった。
とは言っても、Webサーバ・メールサーバ等の本番ドメインを収容している所ではやりたく無い為、
検証用の権威DNSを何かしら構築する方針で考えている。
仮想サーバのリソースも余っているし、予備のグローバルIPも残っている上、
逆NATすればゲートウェイルータ経由で応答させる事も可能なのだが、
検証用途で本格的なサーバを構えるのも大変なので迷っている所。
当初の予定通りラズパイ4を使う案が第一候補になっているのだが、
ラズパイ4は発熱量が凄いのでコレからの時期を乗り越えられるかが懸念点となった。
発熱を回避するには送風して強制的に冷やすか、物を変えるのが手っ取り早い。
ただ、検証用にラズパイ4を用いるのも勿体無いので二の足を踏む状態になっている。
色々な要因を回避する為にサーバ構成を練るのも楽しい一時なので、
この時を考えつつ構成検討を進めようと思う。
2020年06月14日(日) - 19:35 | カテゴリ:
Linux
自鯖刷新によって様々なインフラを見直したのだが、実は権威DNSの構成変更は行わなかった。
刷新直前にグローバルロードバランサを組み込む構成変更を行ったのと、
権威DNSが止まるとサービス停止に陥るので、見直しをした上で安全重視で従来構成を踏襲した。
権威DNSは、グローバルIPを応答するインターネット向け権威DNS(インターネットドメイン)と、
プライベートIPを応答するイントラ向け権威DNS(ローカルネットドメイン)で分離する構成にしている。
インターネットドメインの方は、前回の権威DNS構成変更から基本設計を変更せず、
フロントエンドにdnsdist・バックエンドにBINDとgdnsdで処理する様にしている。
ローカルドメインは親ドメインを管理するBINDを最上位に構えつつ、
下位の権威DNSにサブドメインを委任する構成を取っている。
インターネットドメインは『dnsdist + BIND + gdnsd』の複合構成、
ローカルネットドメインは『BIND』単一構成と『dnsdist + PowerDNS』複合構成にした。
世間では、BIND脱却の為にNSDやPowerDNSを利用する機会も増えてきており、
いざという時に追従出来ないのは問題なので、少し囓った事のあるPowerDNSを使っている。

「自宅サーバでここまで必要か」と言われると不要だと思うが、
本職絡みでもDNSサーバ知識が必須なので、技術検証を柔軟に出来る様に上記構成を取っている。
………
今回のサーバ刷新時に構成変更を行っていないので紹介出来る内容が少なかった (´・ω・`)
唯一の変更点は、レジストラに管理を委任していた他の検証ドメインも集約化を行い、
正引き・逆引き合わせて最終的に9ドメインを管理する体制にした事。
また、ドメイン集約化を行った事でドメイン管理が複雑化したので、
従来利用していたDNSゾーン適用ansibleを見直し、マルチドメインでも簡単に管理出来る様にした。
自鯖の刷新前後を比較して大きな変更点が無い為、権威DNSについて書く事も少なくなくなった。
とは言っても自鯖刷新で大きく構成変更した、仮想サーバ基盤と録画サーバはまだ紹介出来ていないので、
近いうちに書こうと思う。