Home Lab初心者のためのハードウェアガイド

 (linuxblog.io)
2 ポイント 投稿者 GN⁺ 2024-03-09 | 1件のコメント | WhatsAppで共有
  • Home Labは、自宅でネットワークやサーバー構成を安全に実験するためのサンドボックス環境であり、リモートバックアップやモニタリングから機器テストまで、本番環境への負荷を気にせず扱える
  • 導入前には、温度、換気、電源、騒音、ほこり、ケーブル経路といった物理的条件を先に確認し、自宅の構造に合ったネットワーク図を描いておくとよい
  • ラックとキャビネットは機器の奥行きや発熱によって選び方が変わり、浅いネットワーク機器と奥行きのあるサーバー機器を同じ基準で選ぶと、冷却性やアクセス性が損なわれることがある
  • ISPモデム、ルーター・スイッチ、UPS、パッチパネル、ケーブル、サーバーを最初からすべてそろえる必要はなく、小さな構成から始めて電力と拡張余地を調整していくのが現実的
  • 2020年に12Uラックから始めた構成は、6年で10Gアップリンクと2.5G LANまで拡張されたが、重要なのは高価な機器よりも運用可能な配置と電力管理にある

Home Labの目的と運用範囲

  • Home Labは、自宅で安全に実験できるテスト環境であり、新しい設定を本番機器に直接適用するリスクを減らせる
  • 運用例は次のとおり
    • リモートバックアップ
    • リモートサーバーのネットワーク監視と通知
    • 有線UAP AP
    • さまざまな機器やサービスの実験
  • この構成は2020年に初公開されて以来、継続的に更新されており、2026年3月時点の構成の変化と6年間のタイムラインを含む

設置場所を選ぶ基準

  • Home Labの設置場所は、温度と換気、ケーブル配線、アクセス性、電源、騒音、ほこり、人の往来をあわせて見る必要がある
  • 候補場所ごとの長所と短所ははっきりしている
    • ホームオフィス: 机と機器が近くケーブルを短くできるが、ホームオフィス自体がない場合や、すでに長時間過ごす空間である場合がある
    • リビング: 比較的涼しくスペースもあるが、人通りが多く破損のリスクがある
    • クローゼット: アクセスしやすく隠しやすいが、換気とスペースが不足しやすい
    • 地下室: 比較的涼しいが、浸水やアクセス性の問題が起こりうる
    • 屋根裏: 騒音が少なくケーブル配線もしやすいことがあるが、地域によっては高温・雨漏り・湿気の問題がある
    • ガレージ: 室内の騒音を減らせて目立ちにくいが、虫・熱・ほこり・長いケーブル・車両による破損のリスクがある
  • 実際の構成ではホームオフィスに設置しており、ノートPC・デスクトップ・サーバー・その他の機器が同じ空間にあるため、ケーブル配線を短く保てた
  • 設置前にはホームネットワーク図を描くか、ネットワーク設計ツールを使って配線経路と家の構造を先に確認するとよい

ラック、キャビネット、機器収納方式

  • ネットワークキャビネット・ラックとサーバーキャビネット・ラックは混同されやすいが、ルーター・スイッチ・パッチパネルは通常サーバーより浅く、発熱も少ない
  • サーバー用機器を入れる予定があるなら、ネットワークキャビネットでは奥行きや換気が不足する可能性があり、ガラス扉付き製品は放熱に不利なことがある
  • キャビネットとラックを選ぶ際は、まず設置環境を見るべき
    • 大型で重いサーバーを設置するなら、キャビネットや4面ラックの安定性が重要
    • 機器の側面・背面に頻繁にアクセスするなら、オープンラックや側面着脱式キャビネットが有利
    • 追加冷却が必要な機器では、密閉型キャビネットの換気設計がより重要
    • ほこりの多い部屋では、キャビネットのほうが機器保護に向く
    • リビングのように来客のある空間では、施錠できるキャビネットのほうが見た目をすっきりさせやすい
    • アクセス制限やセキュリティが必要なら、ロック機構付きキャビネットが適している

推奨ハードウェアと選定基準

  • 製品価格はAmazonの現在価格基準のため変動することがあり、一部のAmazonリンクは報酬型リンク

  • ISPケーブルモデム

    • 初心者は、ラック全体を組む前でもISP提供モデムを交換するだけでホームネットワーク実験を始められる
    • 米国の多くのISPはモデムのレンタル料を毎月請求するため、自分で購入することにコスト面の意味がある場合がある
    • ISP提供のモデム・ルーター一体機は品質が低かったり中古だったり、機能が不足していたりすることがあり、新たな脆弱性が見つかった際のファームウェア更新をISP任せにせざるを得ないこともある
    • 良いISPと十分な機器を使っているならそのままでもよく、交換の理由は追加のネットワーク機能とHome Labの実験環境を確保するため
    • ケーブルインターネットの例として、Motorola MB7621 32×8、Motorola MB8611 DOCSIS 3.1モデルがある
    • 光回線では、事業者によってはONTを自分で交換できる場合もあるが、多くの構成ではONTはISPが管理し、ユーザーはルーター以降を制御する
    • ケーブルモデムは発熱が大きいため、ラック上部に置くか、上下に空気が流れるスペースを確保する必要がある

  • ラック

    • ラックユニットのUまたはRUは1 3⁄4インチ、44.45mmで、19インチ・23インチラックフレームや機器の高さを表す単位
    • 一般的なフルサイズラックの高さは42U
    • 例示機器:
    • ラック機器を測る際は、ラック内部の幅ではなく、ラック棚板の幅と機器の幅を比較する必要がある

  • UPS

    • プロパンのバックアップ発電機があり切り替えに約1分かかる環境だったため、100W〜200Wの負荷を数分維持できるUPSが必要だった
    • CyberPower OR500LCDRM1U UPSは500VA/300W、6口コンセント、AVR、1Uラックマウント製品で、重さは約20lbs
    • このUPSは、バッテリーを約50%まで使った際に、PoE AP 2台と27インチモニターを含めて30分を少し超えるランタイムを示した
    • UPSは長時間稼働を目指すとコストが大きくなるため、必須の低消費電力機器を安全にシャットダウンできる時間を確保する構成が現実的
    • PoE APはそれぞれ最大約9Wで、UPS負荷を20〜30%程度に抑えるのに役立つ

  • 棚板と電源

    • 1U UPSにラックマウントがない場合は機器の上に置けるが、バッテリーを涼しく保ち熱の蓄積を減らすには通気型1U棚板が適している
    • AC Infinity Vented Cantilever 1U Universal Rack Shelfは奥行き6インチから16インチまであり、通気孔とスロットが冷却とケーブル整理に役立つ
    • CyberPower UPSには6口のコンセントがあり、このうち4口はバッテリーバックアップとサージ保護、2口はサージ保護専用
    • ADJ Products AC POWER STRIP PC-100Aは1U CyberPower UPSに直接接続でき、機器ごとの電源オン・オフを簡単にできる
    • コンセントセーバーと1Uブランキングパネルは、電源活用とラック内のエアフロー改善に使える

冷却、ネットワーク、ケーブル、サーバー構成

  • 冷却

    • ラック機器の適切な温度維持は、過熱防止、一貫した性能、寿命延長に重要
    • AC Infinity CLOUDPLATE T7-N 2U Intakeは約4年間使用し、低いファン速度でもラックを十分に冷やせた
    • ほこりの蓄積により約2年後からファン故障が始まり、3年目には4基中3基のファンが故障した
    • 内部コネクタが基板にホットグルー固定された3ピンのウェハコネクタだったため、ファン交換は難しかった
    • 2025年4月にこの機器を取り外し、1U通気パネルを使う受動冷却へ移行し、その後は問題なく動作している
    • エアコンがありほこりの少ない環境では、能動冷却ファンは不要な場合があり、必要なら数か月ごとに圧縮空気で清掃することで2〜3年の寿命を期待しやすくなる

  • ルーターとスイッチ

    • ルーティングとスイッチングの要件は、Cisco、Ubiquiti、TP-Linkの機器で大半を満たせると考えている
    • この構成はホームオフィスというより小規模ビジネス向け機器に近く、将来の機能拡張も見据えている
    • ルーター例:
      • Peplink B-One Gigabit Dual WAN WiFi Router: Multi-WANロードバランシング、1Gbpsスループット、WAN 2ポート、LAN 4ポート、デュアルバンド2x2 MIMO Wi-Fi
      • Ubiquiti Dream Machine UDM Pro: 10G、マルチギガビット、PoE、オールインワンのルーター・セキュリティゲートウェイ
      • TP-Link ER8411 10G VPN Router: 最大10個のWANポート、SPIファイアウォール、Omada SDN、ロードバランス、雷保護
      • MikroTik RB4011も小型高性能機器の例として挙げられる
    • スイッチ例:
    • Netgear、pfSense、OPNsense、IPFireなど他の選択肢もあり、推奨機器のすべてが各自の要件に合うとは限らないため、別途調査が必要

  • パッチパネルとケーブル

    • 16ポートのパッチパネルを選んだが、振り返ると24ポートを選ぶべきだったと考えている
    • それでも6年後の時点で16ポートはぎりぎり十分な水準
    • ISPの最速プランは下り160Mbps、上り30Mbpsで、Home LabにCAT8やCAT7は必要なかった
    • 1000Mbpsの上限で十分だったため、250フィートのCAT6リールと複数長さのCAT6ケーブルを購入した
    • よりスムーズなネットワークトラフィックが必要ならCAT6a以上を検討できるが、RJ45コネクタやパッチパネルが対応していなければ、CAT7やCAT6aケーブルは無駄になる
    • 初期設置時には同軸ケーブルが約3フィート足りなかったため、必要長より長めのケーブルを見込んで予算を立てるとよい

  • サーバー

    • サーバーは、NAS、VM、Webサーバー、バックアップサーバー、メールサーバー、広告ブロックなど何をホストするかで要件が大きく異なるため、特定モデルは推奨していない
    • 実際の構成では、eBayで中古購入したThinkCentre M73とThinkCentre M715qを使用している
    • どちらの機器も静かで冷却性が高く、Ubuntu ServerとWindows 10を実行している
    • 本格的なサーバーとしてはDell、HP、Cisco、Lenovo製品が選択肢であり、Home LabではCraigslistやeBayで中古購入することが多い

シンプルな全館VPN構成の例

  • 友人向けに構成した全館VPNは、700VA UPSで40W未満しか使っておらず、Home Labが必ずしも複雑だったり電力を多く消費したりする必要はないことを示している
  • 構成要素は次のとおり
    • StarTech.com 6U Wall Mount Network Equipment Rack
    • AC Infinity Vented Cantilever 1U Universal Rack Shelf
    • C2G 12-Port Patch Panel
    • VCE CAT6 RJ45 Keystone Jack Inline Couplers
    • Raspberry Pi 4 2GB Basic KitでUnifi Controllerを実行
    • Brume GL-MV1000でEdge GatewayとWireGuard VPNを実行
    • Edgeswitch 10xp
    • StarTech.com 8 Outlet Horizontal 1U Rack Mount PDU Power Strip
    • CyberPower SL700U Standby UPS System, 700VA/370W

6年間の変化と結論

  • Home Labは2020年に12U壁掛けラック、ケーブルモデム、EdgeRouterから始まった
  • 6年後には10Gアップリンク、pfSenseファイアウォール、2.5G LANへアップグレードされ、監視はZabbixからCheckmk RAWに置き換えられた
  • 主な変化は次のとおり
    • 2020年3月: 初回ビルド完了
    • 2020年4月: 4Gフェイルオーバー、VLAN、ブランキングパネル、Zabbix監視を追加
    • 2020年5月: Raspberry PiとZabbixダッシュボードモニターを追加
    • 2020年6月: キーボードを追加し、メッシュカバーを色付きプレキシガラスに交換
    • 2022〜2023年: 新居へ移転、EdgeRouterをPeplink Balance 20xに交換、UPSをアップグレード
    • 2025年以降: 10Gアップリンクと2.5G LAN、pfSenseファイアウォールへアップグレード、ZabbixをCheckmk RAWに置換、受動冷却へ移行
  • 最も重要な運用原則は、小さく始めて成長に備えること
  • 最初の日からラック、キャビネット、パッチパネル、すべての機器をそろえる必要はなく、ISPモデムの交換と適切なルーターの追加から始められる
  • 機器を選ぶ際は、消費電力を最初から考慮することで、電気料金が過度に増える事態を避けられる

関連記事

1件のコメント

 
GN⁺ 2024-03-09
Hacker News の意見

  • 記事は良いが、規模と範囲が大きくて気後れしやすい。ホームラボは机の上の NUC 1台でも十分に始められるし、64GB RAM があれば本当に多くのものを載せられる。
    NUC は 24/7 稼働の効率が良いが、CPU 負荷が長く続くとうるさくなる。そういうときは eBay で OptiPlex や Precision Tower SFF、できれば ECC 対応モデルに拡張するとよい。Dell SFF は小さいが、ちゃんとしたデスクトップ/サーバーに静かなファンがあり、eBay で40ドルの 10G Mellanox 3 カードも入り、横に積み重ねやすい。第12世代 CPU 以前の OptiPlex は電力とスペースが制約になり得るので避けたほうがよく、i5-12500 の中古はすでにかなり安い。LGA1700 なら必要なときに i9-14900 non-K も載せられる。

    • ラックを必須構成要素としてあまり深刻に考える必要はない。ラックは格好いいし、ホームラボのラックも見栄えはするが、使いやすさと学習が目的なら、単に気に入ったものを使えばよい。
      個人的には、隅に箱を4台積み上げ、作業台の裏にラックのサイドパネル2枚をボルトで留めた偽ラックに部品をネジ止めして使っている。棚の上の NAS と複数の Raspberry Pi もつながっていて、このごちゃごちゃした構成が気に入っているし、多くを学べた。手元にあるもので始め、必要になったら拡張すればよい。ラックは趣味が深まり、スタイル点を気にするようになったときに格好いいものだ。
    • Intel NUC はホームラボをやる人にとって、ばかげているほど良い。最近何台か買ったが、特に消費電力が素晴らしい。
      tasmota ベースのスマートプラグにつないでみたところ、アイドル時はおよそ 6W だった。BIOS 設定と tuned プロファイルで低電力チューニングはいつもしているが、概して NUC が 30W を超えることはめったにない。昔のタングステン電球1個の半分ほどだ。
    • 最初のホームラボは、壊れたモニター付きのノートPCだった。Ubuntu server を入れるのはそれほど難しくなく、ギガビット Ethernet ポートが内蔵されていて、USB 3.0 もあったので NAS として使うのに十分なハードディスク速度を出しやすかった。
      古い中古ノートPC、特に画面が割れたものはほとんどタダ同然で買えるし、すでに持っているか知人がくれれば本当に無料だ。Plex 程度が目標ならうまく動くし、ノートPCの消費電力も、特にアイドル時は NUC より大きく多いわけではない。今は見た目が良いのでちゃんとしたラックマウントサーバーを使っているが、ほとんどの人には古いノートPCで十分だと思う。
    • 始めたばかりの人の多くにとっては、安いリサイクル品のデスクトップ1台や Raspberry Pi 1台で PiHole のようなものを動かし、そこから拡張するほうがずっと価値がある。私のホームラボ[0]も PiHole を動かす Pi 1台から始まり、今では Jellyfin、Calibre、DNS など必要なものをすべて動かす4台構成に成長した。
      ただ、後でラックマウントして一部のハードウェアをアップグレードするときには、この「入門者」向けガイドが本当に役に立った。
      [0] https://blog.janissary.xyz/posts/homelab-0
    • 私の「ホームラボ」も、完全に隠すか、存在理由のある場所に小さなコンピューターを何台も押し込んだ構成だ。古い Celeron NUC はソファの下で Pi-Hole、Syncthing、診断ツールを動かしており、電気代への影響は無視できる程度だ。
      Lenovo のミニPCはテレビの裏で Syncthing ノードと HTPC を兼ねている。世界で最も洗練された構成ではないが、よく動き、とても安く、アパートに合った構成だ。

  • 少し脇道にそれるけれど、ホームサーバーには Proxmox を本当に称賛したい。25年間、自宅で何らかの形で Linux サーバーを動かしてきて、いつも Ubuntu のような単一システムを手作業で管理していたが、ものすごく面倒だった。
    Proxmox は、1台のハードウェア上で複数のコンテナや仮想マシンを簡単に動かせるようにしてくれる。最初は大きな Ubuntu システムを1つ仮想化するところから始めたが、それだけでもバックアップや高可用性といった利点がある。今ではサービスをそれぞれコンテナに分離し始めていて、ずっとすっきりしている。

    • Proxmox は素晴らしい。使っていなかった2台のマシン、ほぼ10年前のもの1台と、5950X を積んだ比較的新しいマシン1台でクラスタを作った。これで、すべてのサービスが入った Debian ボックスが1台死んで全部吹き飛ぶのでは、と心配しなくてよくなった。
      仮想マシン自体も有用だが、Proxmox が提供するマシン間の移行、集中バックアップ／リストアツールは本当に解放感がある。最近は Windows VM に PCIe GPU パススルーを付けて、Moonlight/Sunshine で家の中の非力なマシンにゲームをストリーミングできるようにしたが、あまりにうまく動くので、実際のゲーミングPCは隅でほこりをかぶっている。唯一の不満は、もっと安い有料ライセンスがあればいいのに、ということだ。受け取っている価値に報いたいが、CPUあたり年100ドル以上は趣味用途には高すぎる。無料ティアがまったく煩わしくないのはありがたいが、中間の段階があるとよい。
    • Proxmox は、特に Linux に慣れたホームラボ初心者には非常に役立つ。学びながら複数の環境を簡単に作ったり消したりできる。
      ただし、ストレージ全般は簡単ではない。さまざまな選択肢の結果をきちんと理解するのは難しく、zfs、lvm、lvm-thin、再パーティション化などにかなり慣れていないと、NAS の基盤を適切にセットアップするのは難しい。
    • まだ単一の巨大なホームサーバーという技術的負債に閉じ込められているので、自分も移行を考えている。いつも気になるのはストレージの部分だ。このサーバーは SMB でファイルを提供し、Plex でメディアを提供する NAS でもある。
      ある人たちはデータ配列[1]を Proxmox に直接マウントし、Plex のようなストレージ層の上にあるものだけを仮想化していると聞く。一方で、HBA[2] を NAS VM に PCI パススルーする人たちもいる。前者の利点は、ループバック SMB/NFS/9p の代わりに LXC コンテナへ直接バインドマウントできる点だと思う。また、TrueNAS や Unraid をベアメタルの基盤として使い、ストレージとハイパーバイザーを一緒に担わせる人たちもいて、これも筋が通っている。TrueNAS の Linux 版も、もう成熟する時間があったはずなので、試してみるべきかもしれない。Intel プロセッサ内蔵の Quicksync でハードウェアトランスコーディングも使っているが、VM 越しに使う際に問題があるのか気になっている。おそらくローカルの Proxmox TTY は諦めることになりそうだ。
      [1] VHD ではなく、実際のファイルが入っている配列のこと。そもそも分けておくほうだが、すべてのデータを SSD に置く余裕はなく、HDD に OS ルートを置くのも耐えられないので、必要でもある。あるいは、ファイル用データセットと VM ルート用の zvol または NFS を持つ、単一のマスター ZFS 配列が理想かもしれない。
      [2] 個別の SATA パススルーより信頼性が高いと聞いたが、より大ざっぱに束ねられるという欠点がある。つまり VM がすべてのポートを排他的に制御するため、配列ではないディスクをそこに接続できない。
    • もちろん、Ubuntu システム上でそのままコンテナを動かすこともできるし、バックアップを取れないわけでもない。それでも新しいサーバーなら、最初から ハイパーバイザー で始めるほうがよい。
      別のディストリビューションや非 Linux 系も混在させられるので、柔軟性が高くなる。たとえば私は OPNsense ルーターを動かしている。Proxmox の代わりに xcp-ng を使っている。
    • Proxmox で VM を動かすと、正確にはどうやって 高可用性 が生まれるのか気になる。

  • これが新しい「I use Arch btw」ミームになるのは分かっているけど、この道に進むならディストリビューションとして Nix を強くおすすめする。理想的には一度動くようにしたら、そのまま起動し続ければいいのだが、Nix を使うとシステムの状態がすべて git に記録される。
    もう「6か月前にこれをどう直したんだっけ？」となったり、Ubuntu のディストリビューションアップグレードが壊れたあとに手作業でシステムを組み直したりする必要がない。変更したもの、インストールしたパッケージ、設定した値がすべて git のログにある。自分も、インストール済みのものやシステム構成を確認するドキュメントとして git リポジトリをよく見ている。

    • I use nix btw. 完全に同意。Nix と NixOS はしばしば苦痛だが、いったん動くようにすると本当に素晴らしい。
      複数のデバイスにシステム／ユーザー／アプリケーション設定を素早く簡単に同期できるのは驚きだ。宣言的なアプローチのおかげで、動くようにするまでの苦労が報われ、一度分かれば同じことを二度と繰り返さずに済む。宣言的なので、動作する設定例がドキュメントとして残り、そこから拡張できる。今は Nix で「Linux from Scratch」をビルドしながら Nix の開発環境を学んでいるが、遅いものの、成功するたびに再現可能な状態として固まっていく。LLM は散在した貧弱なドキュメントを要約するのに確かに役立つが、それでもかなりの粘り強さが必要だ。全体として Nix をとても楽しんでいて、ホームラボでもっと活用したい。
    • Nix の学習曲線がもっと緩やかだったらいいのに。あるいは自分がもっと賢ければいいのに。いつか触ってみたいリストには入っているが、そのリストは長く、まだ山を越えられていない。
      概念は理解できるが、新しいパッケージやアプリを試したいときは、Nix 流で頭を抱えるよりも docker-compose と VM のほうが早くたどり着ける。
    • ちなみに自分はホームラボで Arch を使いながらも cattle not pets を実現している。Arch のインストールメディアには cloud-init が入っているので、サーバーを一から作るモジュール入りの cloud-config を別の USB に入れ、ラベルが cidata のドライブとインストールメディアを一緒に挿して電源を入れればいい。
      Nix のほうが簡単だったかは分からないが、cloud-init は、こういうことをする人ならすでに使い方を知っていそうなスクリプトを実行できるようにするだけなので、別の DSL は不要だ。誰かは「YAML は嫌い」と言うだろうが、ホームラボに関心がある人は職場でも複数のサーバーを管理している可能性が高く、cloud-init、Ansible、Kubernetes、あるいは選択肢なく YAML を使う何かを避けられない。ホームラボの目的が、他人のものを壊す可能性なく仕事でやっていることを練習することにあるなら、どうせ使う必要のあるツールに慣れ、自宅環境を職場とあまり違うものにしないほうがいい。もちろん Hacker News の多くの人は、自分とは違って「ホームラボ」を、家族や友人のためのメディアサーバー、チャット、写真共有などをセルフホストするという意味で使っており、実際のデータセンターを練習するためのミニデータセンターという意味では使っていない。
    • 自分も最初は複数の RasPi でそれぞれ違う Raspbian バージョンを動かしていたが、設定ドリフトに疲れて全部 Nix 化した。単一の Nix Flake を書いて、すべてのデバイス向けの宣言的な SD カードインストールイメージをビルドできるので、複数マシンの管理が本当に夢のように楽になった。
      興味があれば、チュートリアルはここ[0]にある。唯一の問題は Nix 設定をリモート配布する部分だ。唯一のファーストパーティ製ツールである nixops は実質的に放置され、サポートも打ち切られた状態だ。morph や deploy-rs のようなコミュニティツールは有望に見えるが、Flakes 対応や活動状況／長期的な持続可能性はまちまちだ。
      [0] https://blog.janissary.xyz/posts/nixos-install-custom-image
    • Ubuntu のディストリビューションアップグレードが壊れたあとにシステムを組み直す羽目になるのは、Linux マシンで Gentoo Linux を動かすことで避けている。Arch も良いとは聞くが、使ったことはない。
      Ubuntu は単純にいまいちだ。昔は何年も Ubuntu を使っていて、非専門家にも安定して使いやすい Linux ディストリビューションをついに推薦できるようになったと本当に喜んでいたが、インプレースアップグレードが2、3回連続でシステムを壊し、Gentoo のよく文書化されたインストール手順と、何年もの試行錯誤で得たシステム管理者としての知識がなければ直せない状態にした後は、見切りをつけた。友人に Ubuntu を使わせてはいけない。

  • 何年もの間、自分の機材を IKEA FRIHETEN ソファ の中に入れていた。利点はアクセスしやすいこと、電源ケーブル1本＋光 WAN 1本＋イーサネット LAN 1本以外は完全に見えないこと、構造上ケーブルを外へ出しやすく、内部の配置や配線もしやすいことだ。
    騒音低減もタダで付いてきて、冬には座ったお尻が絶対に冷たくならない程度の暖房にもなる。配偶者は点滅するライトをまったく見なくて済むので喜び、UPS とディスクベイを買ったことにも気づかなかった。欠点は、中で作業するのが少し不便なこと、座ったり開閉したりすると振動があり、回転式ハードディスクが嫌がるかもしれないこと、熱は意外と大丈夫だったが、クローゼットより悪いわけではなかったことだ。液体をこぼすリスクはあるが、設計上、中に入るより周囲に流れる傾向があり、最悪の場合はハードウェアの下に受け皿を置けばよい。掃除で家具を動かす配偶者がケーブルを引っ張る可能性があるので、余裕を持たせる必要がある。
    † https://www.ikea.com/us/en/images/products/friheten-sleeper-...
    †† 後ろの隅に配線してから最寄りのコンセントまで壁の中に隠したので、実際には見えなかった。

    • IKEA KIVIK ソファのベッドではないモデルでも似たようなことを考えた。広くて角ばったアームレストが下側に開いているので、小型の SFF PC タワーやラックマウント機器を横から入れられそうで、座面の下にもラックマウント機器が入るスペースがある。
      結局やらなかった理由の一つは、機器のすぐ上や周囲がソファという燃料になる火災が嫌だったからだ。サーバー本体よりも UPS が少し心配だった。その区域を板金で補強し、UPS バッテリーの種類によってガスが出る可能性があるなら換気を良くすれば少し安心できただろうが、作業が大きくなりすぎる。結局、機器は布素材から離したラック／棚に置き、目視で確認できるようにした。
    • 本当にすごい。サーバーを中に入れた実際の写真のようなものがあるのか気になる。
      換気、熱、火災リスクがかなり心配になりそうだ。lack rack を思い出す。
      https://archive.is/Uf2k3

  • ホームラボの世界全体が素晴らしい。人によって低消費電力、興味深いプロセッサ、データの所有権、高可用性、UPS／家全体のUPSといった目標があり、こうした重なり合う関心事とソフトウェアが交わる共通の場所が自宅だという点が面白い。
    業界の専門家が趣味で遊んでいるケースから、業界外の人たちまで引き込む人々の幅広さも興味深い。自分もすっかりハマっていて、少なくとも自分にとっては初期のインターネットの魔法のような感覚をよみがえらせてくれる。

    • コミュニティが本当に素晴らしい。RedditやLemmyで非常に活発で、人々はいつも素早く解決策を見つけてくれ、ベストプラクティスとして設定するための助言をくれる。こういうことを学ぶのが面白いなら、本当に宝石のような場所だ。

  • 別の観点から見ると、自分のホームラボはこうだ。場所は地下のオフィスの棚の上で、換気は問題なく、WiFiは悪くないがすごく良いわけでもない。
    ハードウェアは近所の交換会で拾ってきた古いPCで、別の古いPCから抜いたRAMを追加し、ハードディスクとWiFiカードを買った。ソフトウェアはDebian stableとpodman/podman-composeだ。便利なサービスはすべてcomposeファイルの入ったフォルダで、podman-composeでsystemdユニットに変換して使っている。記事に出てきた構成が好みなら、それは素晴らしいことなので好きなだけやればいい。でも必ずそうする必要はないし、特に最初からそうする必要はまったくない。この古くてほぼタダのPCで、家族が毎日使うサービスをいくつも動かしているが、16GB RAMの半分も使っておらず、CPU使用率も5%を超えない。

    • 自分が一番気に入っていたホームラボ構成は、古いノートPC（もともとはXPだったがUbuntuに入れ替えたもの）と拾ってきたUSBドライブをいくつか、ファイルキャビネットの一番上の引き出しに入れていたときのものだった。
      背面にケーブル用の穴を開けてあり、発熱が十分少なかったので空気の流れが問題になったことはなかった。個人Webサイトと水槽のWebカメラをホストし、ドアベルに接続し、XMPPやドキュメント保管庫としても使っていた。サーバーが必要なものは何でもそこに入れていた。引っ越し後は古いMac MiniをNASとして使うようになり、その後はあまりいじる時間がなくなった。
    • 同じように、自分のホームラボは隅に押し込んだ古いゲーミング機で、systemd経由でdocker composeサービスをいくつも動かす構成だ。
    • ほとんど自分の話かもしれない。違いは、自分の「サーバー」がリース返却品のDell Micro PCで、RAMを最大まで積んでProxMoxを動かしており、複数のVMとSynology NASに保存されたデータがすべて地下のオフィスのクローゼットにあるという点だ。
      リモートアクセス用にtailscaleも設定してある。

  • 時間をかけて作り込んだかなり大きなホームラボがあり、うまく動いているのでとても気に入っています。ただ本当の問題は災害復旧です。全部を複製しようとすると永遠にかかりそうですし、すべてを覚えていられるかも分かりません
    ルーター設定、スイッチ設定、NAS、複数のVLANに散らばったDockerコンテナなど、ネットワークは最初に図にしておいたものの、時間がたつにつれて最新状態を保てなくなりました。インフラ図を描き、文書化し、最新の状態に保つための良いツールがあるのか気になります。バックアップとアップグレードも常に問題です。コンテナを1つ作っておいて、6か月後に見返すと何をしたのかまったく分からないことがよくあります。NUC、NAS、デスクトップ、サーバーなど複数のマシンに数十個のコンテナが散らばっていて、サービスごとにbind mountの場所、実行ユーザー、権限の慣例がすべて違うように感じます。頭の中に全部入れておくことはできませんし、特に時間がたった後はなおさらです。中央のインターフェースからバックアップ、復元、アップグレードだけ押せるとよいのですが。昔のVM clone/snapshotでcattleのように運用していた頃が懐かしいです。ProxmoxマシンにはまだいくつかVMがあるのである程度似たことはできますが、ホームラボ全体にはそういう仕組みがありません。理論上は家が燃えても全構成を完全に復旧できる地点まで行きたいです。自宅構成管理でKubernetesまで行くよりも、もっと単純な方法がきっとあるはずで、皆さんが何を使っているのか気になります

    • 核心的な問題は一貫性の欠如に見えます。まずはデバイスの種類やデプロイ方式などの数を減らすところからやってみます
      1人か2人で広く拡張するのは難しすぎますが、1つのスタックを深く掘ればよく分かるようになり、すべてがまったく同じ方式なら、全部動くか全部動かないかに近い状態になります。結局、すべてが正しく動かなければならない構造になります
    • 去年、誤ってサーバーのドライブを消してしまいましたが、自分の構成のおかげでそこまでひどいことにはなりませんでした。戦略は、すべてのプロジェクトフォルダにdeploy.ps1スクリプトを置くことです
      80%はVMを作る、rcloneでファイルをコピーする、必要ならサービスをインストール/起動する程度で、カスタムコマンドを使ってだいたい3行です。VMが起動していればデプロイは100msほどで終わります。たまにスクリプトがもっと複雑になることもありますが、基本的な考え方は、内部でどんなシステムを使っていてもdeploy.ps1を実行すれば、インターネットなし、依存関係なしで、宇宙の熱的死まで動き続けるようにすることです。すべてを失った後でdeployを再実行し、リストにまとめて全体を復旧しました。ルーティング設定の文書化が100%ではない点には同感です。自分のルーター/スイッチ設定も正直かなり複雑なので、減らすべきだと思います
    • FrameworkやSystem76のような会社が、Nix/Guixがビルドを管理するようにハードウェアをコード化する再現可能な製造プロセスを出してくれるとよいのですが。災害復旧がずっと楽になるはずです
      Super Micro Computerならすでにできるのかもしれませんが、対象はデータセンターです。夢見ることしかできません
    • インフラの複雑さは役に立っていないようなので、まず減らすところから始めます。私は単一サーバーのFujitsu D3417-B、Xeon 1225v5、64GB ECC、WD SN850x 2TB NVMeにProxmoxを載せ、OpenWRTルーターとしてBanana Pi BPI-R3を使っています
      Proxmoxはアイドル時に約12W、OpenWRTは約4.5Wを消費し、NodeJSでOpenWRT上にMeshCommanderを動かしてリモート管理できます。ZFSのネイティブ暗号化を使っているため、外付けドライブへの全体バックアップはこのように行っています
      # create backup pool on external drive
      zpool create -f rpoolbak /dev/sdb
      # create snapshot on proxmox NVMe
      zfs snapshot -r "rpool@backup-2024-01-19"
      # recursively send the snapshot to the external drive (initial backup)
      # pv only is there to monitor the transfer speed
      zfs send -R --raw rpool@backup-2024-01-19 | pv | zfs recv -Fdu rpoolbak
      増分バックアップは-Iオプションと、開始/終了を示す2つのスナップショットを渡せばよいです
      # create new snapshot
      zfs snapshot -r "rpool@backup-2024-01-20"
      # only send everything between 2024-01-19 and 2024-01-20
      zfs send -RI --raw rpool@backup-2024-01-19 rpool@backup-2024-01-20 | pv | zfs recv -Fdu rpoolbak
      簡単で速く、かなり信頼できます。zfs-auto-snapshotを使えば、ファイルシステムを15分単位で戻せます。仮想マシンのロールバックにもかなり便利です[1]。最近NVMeのSamsung 980 Proが壊れましたが、zfsでバックアップを逆方向、つまりrpoolbakからrpoolへ復元するシェルコマンドを実行したところ、700GBで約2時間かかり、サーバーは再びオンラインになりました。ZFSが、特に暗号化では場合によって「実験的」だということは知っていますが、結果にはかなり満足しています
      1: https://pilabor.com/series/proxmox/restore-virtual-machine-v...
    • 自分のホームラボをもう一度ブートストラップしようとしたのですが、必ず何かを忘れるか「頭の中に全部入れておけない」状態になると分かっていて、行き詰まりました
      そこで文書化に多くの時間を使い、できるだけシンプルで基本に近く、コミュニティのサポートがある方式で作ろうとしています。その結果、まだホームラボも、ここで誰かが呼んでいた「homeprod」もありません。同じ問題意識を持つよう説得している友人も見つけたので、バス係数が1にならないよう、ホームラボの文書と手順を互いにミラーリングしてみようかと思っています

  • 昨年からホームラボ構成をセットアップして維持してきましたが、本当に驚きです。コンテナ、仮想マシン、ネットワーキングについてものすごく多くを学びました。
    paperless-ngx [1] や immich [2] のような一部のセルフホストアプリケーションは、機能面でプロプライエタリなクラウドソリューションをはるかに上回っています。tailscale [3] のような VPN サービスを加えたので、今では世界中どこからでもホームラボにアクセスできます。足りないのは、NUC やミニ PC のような低消費電力マシンを用意して、24/7 必要なサービスを移し、電気代を下げることだけです。維持できて、週末に定期点検やアップグレードをする気力があるなら、自分のホームラボを作ることを 100% おすすめします。
    [1] https://docs.paperless-ngx.com/
    [2] https://immich.app/
    [3] https://tailscale.com/

    • ミニ PC にはぜひ投資したほうがいいです。強力な HP elitedesk を買いましたが、アイドル時は 7W しか消費せず、コンテナを 38 個動かしています。

  • ホームラボ機器が非技術系 nerd の生活空間にあるなら、騒音、照明/ディスプレイ、目立たなさ も考えるべきです。アパート暮らしで長い間クローゼットの中に置いていましたが、リビングに移した後はいくつかの解決策を使いました。
    目立たなくするために、ほかの家具と合う IKEA CORRAS キャビネットを使いました。以前はラックマウント用ポストを入れていましたが、出っ張るので取り外しました。騒音については、ファンレス機器か、少数の Noctua ファンで冷却できる機器を選びました。1U PSU のファンも Noctua に替えますが、多少のはんだ付けと悪態が必要です。結局、データセンターではない環境では、PSU 以外はファンレスで動かせる Atom サーバーをよく使うようになりました。今唯一静かでない 3090 GPU サーバーは、必要なときだけ起動するようにしています。ノート PC から Wake-on-LAN コマンドを実行していますが、IPMI、PDU や IoT コンセントの小技、ソフトウェアで 3090 とファンを止める、Kubernetes 自動化なども可能です。明るすぎる表示 LED は白いラベルプリンターテープで覆うとうまくいき、思ったより見た目も良いです。見る必要のない光には黒いラベルプリンターテープを使います。コンソールは、特に TrackPoint キーボード付きの古い IBM のような、目立たないスライドアウト式ラックコンソールが好みです。リビングに監視用ディスプレイを置くなら、少なくともキーボードはスライドアウト引き出しに入れるでしょう。不要な機器も処分します。そうしないと、今のラックスペースの倍以上が必要になり、リビングでオーディオファイル向け機器のように見せかけるのも難しくなります。アパートで今はルーターまで触りたくなく、サーバーだけ欲しいなら、プラスチック筐体の OpenWRT ルーターも検討に値します。ルーター、スイッチ、パッチパネル数ラックユニット分を置き換えられ、外部 WiFi AP や配線も不要になるかもしれません。

    • 数学の大学院生で、LLM も触ってみたいので、予算の都合から 3060 か 3090 を考えています。ただ 2011 年の MacBook Pro を使っているので、こういう用途にはあまり快適ではありません。
      自分の「要件」を考えると、最低限の予算や支出をどの程度に見積もるべきか気になります。あるいは vast.ai のようなサイトで十分だと考えるかも知りたいです。

  • 30 歳を過ぎたからか、単に ホームネットワーク と、コンピューターが 2 台以上ある状態と呼んでいます。なぜホームネットワークがあるかというと、ここにいる多くの人と同じくネットワークアプリケーションを開発しているからです。
    ネットワーク技術者ではありませんが、TCP/IP や DNS などインターネットのさまざまな構成要素が実際にどう動いているのかを理解するのは本当に有用で、多くの開発者との差別化にもなります。自分のネットワークを自分で制御し、好きなようにできる柔軟性も良いところです。なぜコンピューターが複数台あるかというと、最近は仮想化がかなり良いので、いろいろな OS で遊ぶことが主な理由ではありません。実際には機器の置き場所のためです。ハードディスクはかなりうるさいので食器棚の中に置きたい一方、画面とキーボードは机の上に置きたいのです。なので食器棚には NAS があり、机には静かな PC、リビングには無音のメディアセンターとその他の機器があります。一つ言うなら、ラックマウントサーバー機器の誘惑に負けないことです。見た目は格好よく、中古で安く手に入りますが、家庭には向いていません。代わりに大きなファン付きのデスクトップ PC ケースを使うのが良いです。ラックマウントのネットワーク機器はかなり良いです。

    • サーバー次第です。Super Micro は、ネットワークキャビネットや壁掛けラックに入るほど奥行きが浅く、消費電力も低いラックマウントサーバーを作っています。
      本物の OOB 管理システム もあるので、かなり役に立ちます。 https://www.supermicro.com/en/products/system/iot/1u/sys-510...
      一般的な奥行きの深いラックマウントサーバーは、ホームラボでは手間の割に得られるものが少ないという点には同意します。
    • 私のホームサーバーは、4RU ケースにデスクトップ部品を詰めて作りました。幸い 4RU は大きなファンを入れるのに十分な高さがあるので、かなり静かです。
      ただし 本物のラックマウント機器 を家に持ち込むことを少しでも考えているなら、事前に何らかの方法であのひどい騒音を聞いておくことを強くおすすめします。それに耐えて暮らすのは想像しにくいです。
    • ラックマウント機器も、どこに「ラック」として収まるかによっては問題ありません。気候によってはガレージや地下室などに置けます。
      ただし本物のラックがないとかなり面倒になります。結局、ラックのような塔として他の機器の上に積むことになり、手を入れたい機器にアクセスするには全部解体しなければなりません。リース返却品のラック機器で行くなら、きちんとラックとレールも買うのが良いです。レールは少し高いことがあるので、付属している出品を確認すべきです。レールはサーバーよりずっと長く互換性がある場合が多いため、リース返却機器を大量処分する大企業は通常付属させず、小さな販売者はしばしば付属させています。