MorgothTheBauglirの350TB ZimaBoard 2ユーザーストーリー

Zimaからのメッセージ

MorgothTheBauglirさん、コンパクトなホームサーバープラットフォームが、拡張を固定的な限界ではなく設計ツールとして捉えたときに、どこまで到達できるかを示してくださり、ありがとうございます。DIY NASでZimaOSを知るところから、ZimaBoard 2を350TBを超えるストレージシステムの制御拠点へと発展させるまで、あなたの取り組みは、セルフホスティングコミュニティを価値あるものにする実践的な実験精神を体現しています。

最終的な容量の数字だけでなく、さらに多くのことを共有してくださった点に、私たちは特に感謝しています。ビルドを記録し、ハードウェアの選択とトレードオフを説明し、他のホームラボユーザーからの質問に答え、システムが成長を続け、やがて新たな性能の限界に達した過程でも率直な姿勢を貫きました。そのオープンな姿勢は、他のビルダーにショーケース以上の価値を与えます。実際に研究し、問いを投げかけ、学ぶことのできるプロジェクトです。

— Zima

MorgothTheBauglirについて

MorgothTheBauglirは、ZimaSpaceの以前の350TBケーススタディでIgorとして紹介されたビルダーのReddit上のアイデンティティです。そのプロフィールでは、コンピューター、サーバーアーキテクチャ、データ管理に長年関心を持つブラジル出身のネットワークエンジニアとして紹介されていました。彼のホームラボでの取り組みも同じ方針に沿っています。設置スペースを抑え、実用的なハードウェアは適切な場合に再利用し、実験を続けられるだけの余地を残すことです。

彼のZimaでの歩みは、DIY NASでZimaOSを知るところから始まり、ZimaBoard 2を350TBを超える規模へ成長したストレージビルドの制御拠点へと発展させるまでに至りました。Redditでの公開活動でも、ストレージ、HBA、仮想化、ネットワーク、セルフホスティング、ZimaOSに関する議論を通じて、実践的なアプローチを続けています。RedditでMorgothTheBauglirをフォローすれば、このページの先でも続くプロジェクトや会話を見ることができます。

Redditで共有されたMorgothTheBauglirのコンパクトな350TB超ZimaBoard 2ストレージビルド — MorgothTheBauglirは350TB超のビルドをRedditで公開し、容量の数字の裏にあるコンパクトなラックシステムをコミュニティに直接披露しました。

ZimaOSから専用ZimaBoard 2へ

ZimaBoard 2への道のりは、ソフトウェアから始まりました。ZimaSpaceの初期ケーススタディによると、IgorはNAS Comparesを通じて初めてZimaOSを知り、DIY NASにインストールしました。際立っていたのは単一の機能ではなく、洗練されたインターフェース、軽快な動作、そして基盤となるハードウェアを隠すことなく、親しみやすく感じられるセルフホスティングのワークフローが組み合わさっていた点です。

IceWhaleコミュニティに参加した後、彼はイベントでZimaBoard 2 832を獲得し、ほどなくして上位モデルのZimaBoard 2 1664へ移行しました。これにより、次のストレージ実験では、以前使っていた一般的なミニPCにはなかったものを、同じコンパクトな形で利用できるようになりました。それは、はるかに大規模なシステムの出発点として活用できる、直接接続のPCIe拡張パスです。

1つのPCIe拡張経路を350TB以上へ拡張する

このビルドを際立たせたプロジェクトは、80TBのNASとして始まり、その後も拡張を続けました。2026年1月までに、MorgothTheBauglirは10インチのミニラック内でZimaBoard 2を中心に再構築し、混在ストレージプールを350TB超まで拡大しました。

中核となるハードウェア構成では、ZimaBoard 2にIBM M1210 HBAとAdaptec AEC-82885T SASエクスパンダーを組み合わせました。さらに、HDDとSSDを混在させ、専用の電源分配、アルミ押出材、大量のケーブル、冷却機構、3Dプリント製マウントを使用しています。その結果は市販NASというより、利用可能な部品、容量、スペースに合わせて設計されたコンパクトなストレージ筐体に近いものでした。

ZimaSpaceは、350TB以上のZimaBoard 2ストレージケーススタディで、アーキテクチャ、ソフトウェアスタック、拡張に関する判断を記録しています。元のRedditビルドログには、ワークショップレベルの詳細も加えられています。気流の問題、ドライブキャディ、3Dプリント部品、ケーブル配線、電源分配、そして高密度ラックを実用化するために必要だった小さな工夫などです。

ZimaSpaceの350TB ZimaBoard 2ケーススタディのシステム図 — ZimaSpaceの元のケーススタディに掲載されたシステム概要では、ZimaBoard 2をストレージ筐体そのものとして扱うのではなく、はるかに大規模なストレージ管理設計の中心に据えています。

拡張を設計ツールにする

この構成で重要だったZimaBoard 2の機能は、単により多くのストレージを接続できることではありませんでした。PCIeスロットに実用的なHBAを直接接続できたことです。これにより、ホスト本体を大型の従来型サーバーにすることなく、コンパクトなボードからSAS拡張トポロジーへ移行できました。

MorgothTheBauglirは、その違いを簡潔に説明しています。HBAを直接サポートすることで、コンパクトで高密度なNASの設計方法が変わります。ボード自体は小型のまま、周囲のストレージファブリックをはるかに大規模にできました。

MorgothTheBauglirによるコンパクトなZimaBoard 2ストレージ構成のハードウェア詳細 — ビルド資料に示されたハードウェアの構成からは、専用の拡張ハードウェアによってストレージを拡張し、ホスト本体の設置面積を超えてプロジェクトを発展させていることが分かります。

350TBのZimaBoard 2プロジェクトにおける高密度ラックおよびストレージハードウェア — コンパクトなラック形式では、機械的なレイアウト自体がエンジニアリング上の課題になります。ドライブ、配線、冷却、電源、拡張を、限られたホームラボの設置スペース内で共存させなければなりません。

冷却、電力、スペースもストレージの課題の一部だった

容量だけが制約だったわけではありません。暖かい気候、エンタープライズドライブ、限られた家庭内スペース、そして高密度な10インチラックという条件により、エアフローと電力分配はデータパスと併せて設計する必要がありました。ファン、ドライブマウント、PSUの配置、ケーブルの配線経路はすべて、同じ物理レイアウトに適合させる必要がありました。

このビルドが、見出しになる容量を超えて役立つ理由の一つがここにあります。非常に大容量のホームストレージは、単にディスクを追加接続すればよいという話ではありません。機械的なレイアウト、熱、電力、配線、保守性が、アーキテクチャの一部になります。

MorgothTheBauglirの350TB ZimaBoard 2ビルドにおけるストレージハードウェアと配線 — 容量が増えるにつれて、プロジェクトは生のディスク数だけでなく、配線、物理的な整理、サービスへのアクセス性にも関わるようになります。

ZimaBoard 2の350TBプロジェクトにおけるコンパクトな高密度ストレージ構成 — このビルドを特徴づけるトレードオフは、そのパッケージングに表れています。非常に大容量のストレージを、フルサイズのエンタープライズ筐体ではなく、コンパクトなホストと家庭向けのラックを中心に構成しています。

制約を中心にソフトウェアを選ぶ

ストレージソフトウェアにも、制約を優先する同じ考え方が適用されました。メモリを大量に消費するZFSトポロジーを中心にプール全体を構築するのではなく、仮想化レイヤーにProxmox VEを使用し、ストレージ管理ワークロードには軽量なWindows IoT仮想マシンを使用し、容量の異なるドライブ間で柔軟なプール構成とフォルダーの複製を実現するためにStableBit DrivePoolを使用しました。

ZimaSpaceのケーススタディで彼がまとめた言葉は、意図的にシンプルでした。「誰もがRAIDを必要とするわけではありません。」 重要なのは、あるストレージ設計が普遍的に優れているということではありません。利用可能な選択肢の中で最も複雑だからという理由ではなく、実際のハードウェア、復旧モデル、ワークロードに合わせてソフトウェアスタックを選ぶべきだということです。

MorgothTheBauglirの350TBストレージ管理環境のソフトウェア画面 — このプロジェクトのソフトウェア面は、ハードウェアと同じ制約を前提に設計されました。つまり、コンパクトなホストに不要な複雑さを加えることなく、容量の異なるドライブで構成された非常に大きなプールを管理することです。

350TBのZimaBoard 2ケーススタディにおけるストレージプール管理画面のスクリーンショット — ZimaSpaceの元のケーススタディでは、ハードウェアだけでなくビルドの運用面も記録されています。そこには、容量が異なるストレージプールを整理・管理するために使用したソフトウェアも含まれています。

結果だけでなく、ビルドを共有する

公開ビルドログは、このストーリーの重要な一部です。MorgothTheBauglirは完成したラックの写真を投稿しただけではありません。主要コンポーネントを列挙し、3Dプリント用モデルへのリンクを掲載し、組み立て時の問題を説明し、部品や苦労した点について質問を受け付けました。その後の議論では、消費電力、ネットワーク速度、ストレージの使用状況、アルミ押出材、ドライブマウント、今後のアップグレードについての質問に答えています。

同じ実践的な姿勢は、彼の幅広いセルフホスティングに関する議論にも表れています。Redditのプロフィールでは、SATA拡張向けにHBAをITモードで使用する方法を推奨しており、後の移行に関する議論では、使いやすさを重視する場合の選択肢としてZimaOSを挙げる一方、スナップショット、ロールバック、容易な移行を優先する場合にはProxmox仮想化も提案しています。

限界が見えるまでビルドを拡張する

物語は350TBで終わりませんでした。システムが450TBを超えて成長すると、MorgothTheBauglirは、持続的なCPU負荷と割り込みの発生に加えて、ネットワーク転送が遅くなったと報告しました。ZimaBoard 2の構成は350TBの段階では機能していましたが、より大きなワークロードによって次のボトルネックが明らかになりました。

彼はそれを失敗とは捉えず、アーキテクチャを変更しました。プライマリストレージの処理は、より高性能なホストへ移行しました。そのホストは、より大容量のメモリ、高速なPCIe接続、10GbEを備えています。一方で、ラックと拡張の取り組みも進化を続けました。彼のRedditでの450TBアップデートは、成功したコンパクトな設計が、最終的に異なるクラスのホストを正当化する規模に達した時点を記録しているため、有用な続編となっています。

この進展から得られる教訓は、容量無制限をうたう主張よりも有益です。ZimaBoard 2は、非常に高密度なホームストレージ実験を可能にしました。そしてその実験から、プラットフォームが適していた領域と、ワークロードがその限界を超えた領域について、実際の情報が得られました。

変わらなかったこと

ハードウェアが変化しても、同じエンジニアリングの習慣は一貫して見て取れます。現在の問題を解決する拡張経路を使うこと、見返りのない複雑さを避けること、機械設計をシステムアーキテクチャの一部として考えること、そして他の人が結果から学べるだけの詳細を共有することです。

だからこそ、このユーザーストーリーと技術的なケーススタディの関係が重要になります。350TBの記事ではアーキテクチャを解説し、このページではその構築者、そこに至るまでの判断、そしてプロジェクトが成長し続けたときに起きたことを記録しています。

物語は今も続いている

MorgothTheBauglirとZimaの物語は、今も続いています。このプロジェクトは、より小規模なDIY NASから350TB超のZimaBoard 2システムへ、さらに450TBを超える新たな段階へと移行してきました。新たな制約が現れるたびに、ラック、ストレージプール、ソフトウェアの選択は変化し続けています。

ZimaBoard 2の構成段階の技術的な詳細を知りたい方は、350TB ZimaBoard 2ケーススタディ全文をご覧ください。彼が次に何を構築し、テストし、推奨するのかを確認したい方は、RedditでMorgothTheBauglirをフォローしてください。