DigiLoog

続きを読む »

各サーバのスペックは次の通り。ゲストに割り振っているリソースを考えると、
コレでもCPUコア数が足りずオーバーコミット状態になっている。
ただ、CPU負荷は時間をかければなんとかなる事が多いのと、
金銭的にスペックアップも無理だったので諦めた。

筆者がサーバを組む時はメモリを乗せる事でアプリのキャッシュヒット率を上げ、
CPUとディスクの負荷を下げる構成を取る事が多い為、メモリ搭載量を重視して構成を組んだ。
正直な所、メイン利用しているサーバのCPUコアを増やしたいのが本音だが、
このスペックでゲストサーバを全台収容出来ている上、
処理待ちでゲスト環境が停止する事も起きていないので、当面はホスト増強をする予定は無い。

• KVM環境

Webサーバやメールサーバなど、インターネットに公開している24h365d稼働サーバを収容しており、
ホストサーバは「さくらの専用サーバ」を2台契約して利用している。
既に『自宅サーバ』では無いのだが、メリット・デメリットを考えた上で今回の構成となった。
前世代のサーバで採用していたフル自宅サーバ構成の場合、室温上昇と冷房費が増えていた。
その為、今回は新たな試みとして専用サーバを契約し、ハードウェアを外に持って行ってみた。

フル自宅サーバと専用サーバのコストを比較すると、
専用サーバを用いる方が費用が掛っており本末転倒でもあるのだが、
一番の課題かつ問題だった室温上昇を抑えられたのが最大のメリットだった。

• Hyper-V環境

メイン利用は専用サーバに移行したが、手元に無いと検証出来ない事もあるので一部は自宅に残した。
とは言っても払拭した課題が再燃したら意味ないので、
ベアボーンを用いた省電力サーバを組み、使い安い環境とすべくHyper-Vホストとして稼働させた。
また、老朽化した物理ルータを仮想ルータとして収容する事で電気代の圧縮とリソース活用を進めつつ、
シングル構成の課題があったIPv6ゲートウェイの冗長化も行った。

ベアボーンを使っている事もあり筐体の排熱と温度上昇が懸念点だったが、
フルロードをしなければCPUや筐体温度は40～50度で収まった。
逆にフルロードをすると70～80度まで上がるのだが、ゲストに制限をかけてフルロードを抑制した。
結果、CPUオーバーコミットかつ6C6Tでもリソースを食い潰さず稼働出来るバランスも獲得出来た。

• VMware環境

当初は構築する予定が無かったが、VMware ESXiの運用スキルを修得する必要が出てきた事と、
仮想ルータを増やした事によってNW検証が難しくなったので仮想検証機として構築する事にした。
ゲストにはLinuxとNW検証用のGNS3-VMを準備し、Linux・NWの両環境をテスト出来る様にした。

現在はiSCSI接続をしていないだが、必要となった時に接続出来る様に構築してある為、
ディスク装置の方でVMware用領域を準備すれば、iSCSI接続も出来る様になっている。

………

今回刷新した環境から、自宅サーバと専用サーバのハイブリッド構成となった。
純粋な自宅サーバ環境で無くなって閉まったがコレも時代に合わせた変化の一つだと思う。

エンタープライズ環境だとクラウド上でサーバレス構成を取る機会がが増えているが、
オンプレ回帰するケースも出てきているので、まだまだオンプレ技術も残ると思う。
そうなると、オンプレとクラウドの良いとこ取りをする為に、
ある程度の運用スキルが無いと判断つかない事が出てきそうなので、自宅サーバは今後も必要になると思う。

また、自分で好きに弄れるサーバ・NW環境ほど楽しい物は無いので、好奇心を満たす為にも継続予定。
特に今回はNW検証も出来る環境を設けたので従来以上に自由に弄れる様になった。
最近はNW業界から少し離れていたが、勉強環境が整ったので改めて弄っていこうと思う。

« 続きを隠す

続きを読む »

今回の構成は次の通り。2台目のスペックとほぼ同じ構成とした。
当初、メモリはADATA製を利用しようと計画していたが、G.SKILLが叩き売りをしていた変更。
保証期間が有限なのがネックだがメモリ故障の機会は稀なので、保証期間は許容した。

twitterを見ているとNUCをベースにした仮想サーバや、Kubernetesクラスタを構築している事例が多い。
ただ、筆者の場合は仮想サーバホストを二重化しつつゲストサーバ単位で冗長化する方針を取っている。
今回の環境も同じ方針・構成を取っており、これでゲストOSをフル稼働する環境が整った。

LANケーブルの整理と物理設備の仮想化も進めているのでNWラックがスッキリした環境に。
VMware ESXiを接続する為のゲートウェイ用LANケーブルを仮設しているので、
ルータから1本のLANケーブルが表からスイッチに延びているが後で弾き直そうと思う。

« 続きを隠す

続きを読む »

• 構成図

今回は録画サーバの構成紹介であって、
地デジを復号・録画する様な物じゃないのであしからず。

構成は至ってシンプル。母体となるベアボーン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対応の新バージョンが出るらしい。
来年には活躍しそうなサーバなので、今後も上手く運用していきたいと思う。

« 続きを隠す