Zimaからのメッセージ
完成したアプライアンスではなく、複数のレイヤーを重ねながら成長するシステムとしてZimaCube 2を記録してくださったTedに感謝します。あなたのPioneerビルドには、アップグレードの成功、ストレージベンチマーク、Immichの移行、そして最終的にOCuLinkソリューションへとつながったThunderbolt経路など、対応に苦労した部分も記録されています。ビルドの進行に合わせて測定結果、回避策、失敗、変化するハードウェアの判断を公開することで、あなたはコミュニティに完成したスペックシート以上に役立つものを提供しています。それは、実際のZimaOSホームラボがどのように進化していくのかを示す記録です。
— Zima
ted-knightに会う
Ted-knightは、Pioneer Programで最も計画的に進められているZimaCube 2ビルドの一つを記録しています。彼のZimaCube 2 Buildは、最終構成を一つ決めて進める形式ではありません。代わりに、プロジェクトは複数のフェーズに分けられ、各レイヤーをテストしてから次のレイヤーが追加されます。
このビルドの目的は明快です。重要なデータを安心して任せられるNASを今すぐ構築しながら、将来的なセルフホスティング、メディア、ローカルAI、その他のワークロードに対応できる余地も残すことです。そのため、tedはストレージアーキテクチャ、ZFS、btrfs、RAMとNVMeのアップグレード、OCuLink拡張、ベンチマーク、ZimaOSとの統合、Immichの移行、そしてこのマシンが次にどう進化するかについて、ますます詳細なロードマップの作成へと取り組んできました。
彼はZimaCube 2 Standardから始めました。Intel Core i3-1215U、8GB DDR5、256GB NVMeシステムドライブを搭載したシステムです。しかし、元の構成がそのまま維持された期間は長くありませんでした。
サービスを追加する前にストレージ基盤を構築
Tedが最初に優先したのは、サーバーをアプリケーションで埋め尽くすことではありませんでした。さまざまな種類のデータをどこに保存すべきかを決めることでした。
完成したシステムは、それぞれ役割を意図的に分けた複数のストレージ階層で構成されています。ZimaOSは専用の256GB Kingston NVMeに引き続き配置されています。Crucial P510 2TB NVMeはArctic-Storageとなり、AppData、Dockerイメージ、データベース、その他のアクティブなワークロード向けのbtrfs階層として機能しています。4台の2TB NVMeドライブはglacierを構成し、使用可能容量約5.5TBのZFS RAIDZ1プールとなっています。その後、4台の4TB Seagate IronWolfドライブが、メディアなどの大容量データや使用頻度の低いデータ向けの、12TB btrfs RAID5プールになりました。
このアーキテクチャは、すべてのドライブを同じように動作させることよりも、ワークロードにストレージを適合させることを重視しています。ランダムI/Oの負荷が高いデータベースは高速なP510に配置し、より大規模なシーケンシャルワークロードや、ZFSのチェックサムと冗長性の恩恵を受けるデータはglacierに置けます。大容量が必要なメディアは、より高容量のIronWolfティアに移すことができます。
Thunderbolt 4が機能しなかったとき、アーキテクチャは変わった
tedのプロジェクトで特に有益なのは、失敗した実験も記録に残されていることです。
当初の計画は、Aoostar TB4S-OC 4基NVMeエンクロージャーをThunderbolt 4経由でZimaCube 2に接続することでした。Tedは異なる40Gbpsケーブル、両方のThunderboltポート、外部電源、基盤となるカーネルの挙動を検証しましたが、エンクロージャーは安定したPCIe接続を確立できませんでした。
調査の結果、最終的にZimaOSのThunderbolt構成と、エンクロージャー内部のASMedia ASM2462PDXコントローラーとの相互作用が原因として浮かび上がりました。当初の計画を無理に続けるのではなく、tedはアーキテクチャを変更しました。
PCIe x4 - OCuLinkアダプターをスロット1に取り付けました。AoostarのエンクロージャーはThunderboltから直接OCuLink接続へ移行しました。4基すべてのNVMeドライブが初回起動時に認識され、Thunderbolt構成を妨げていたトンネリングや認証の問題も発生しませんでした。
この変更は、その後の計画にも影響を及ぼしました。スロット1は現在ストレージで占有されていますが、2つのThunderboltポートは、ダイレクトネットワーキングや別のeGPU構成など、将来の実験のために空けてあります。接続の失敗は単なるトラブルシューティングの脚注にはならず、マシン全体のロードマップを変えました。
どのティアが速いかを前提にせず、ストレージをベンチマークする
ストレージの準備が整うと、tedは測定を行いました。
Phase 1.5の作業では fio glacierのZFS RAIDZ1プールとArctic-Storageを比較するために使用し、「NVMe」を単一の性能カテゴリーとして扱わないようにしました。コールドベンチマークでは、glacierはシーケンシャル書き込み1,726 MB/s、シーケンシャル読み取り2,591 MB/sに達しました。一方、単一ドライブのArctic層はランダムI/Oで大幅に優れており、元の配置ではランダム4K読み取りが205,588 IOPSに達しました。
ZFS ARCが関わると、さらに興味深い結果が現れました。glacierからの繰り返し読み取りは、NVMeドライブへ戻るのではなくRAMから提供されます。以前の16GBメモリ構成では、ウォームランダム読み取りが約83,929 IOPSに達し、コールド時の14,781 IOPSを大きく上回りました。
この結果は、後の別のハードウェア判断にも影響しました。Tedは16GBのDDR5モジュールを2枚使用してマシンを32GBにアップグレードし、シングルチャネルメモリからデュアルチャネルメモリへ移行しました。アップグレード後、ウォームARCランダム読み取りはさらに126,816 IOPSへ向上し、以前の結果から実測で51パーセント改善しました。
ベンチマークによって、Crucial P510の当初の配置も見直されました。Standardモデルの7th Bayでは、ブリッジによってシーケンシャルスループットが制限されていました。TedはドライブをオンボードM.2スロットへ移し、シーケンシャル読み取りが874 MB/sから1,677 MB/sへ、ランダム4K読み取り性能が205,588 IOPSから403,078 IOPSへ向上したことを測定しました。
教訓は、単に一方のスロットが速かったということではありません。測定結果によって、どのワークロードをどこに配置すべきか、そして実際に価値のあるアップグレードは何かが変わりました。
ZimaOSと共存させてZFSを動作させる
この構成は、ZimaOSがネイティブに管理する範囲と、経験豊富なユーザーがその下に追加できるものとの興味深い境界も示しています。
Tedは、Arctic-StorageとIronWolfプールには意図的にbtrfsを使用しています。これらのボリュームはZimaOSと自然に統合できるためです。glacierプールは異なります。これはコマンドラインからZFS RAIDZ1として作成され、tedにZFSデータセット、チェックサム、ARCキャッシュ、スナップショットを提供し、計画していた一部のワークロードにより適したストレージモデルを実現しました。
ただし、この柔軟性には難点もあります。コマンドラインから作成したZFSプールは、インターフェース上でZimaOSのネイティブストレージボリュームとして表示されません。
Tedの回避策はシンプルで実用的です。個々のZFSデータセットを、以下の配下にシンボリックリンクで公開します。 /DATA、glacierのドキュメント、メディア、バックアップ、VMストレージなどのパスを、基盤となるプールをZFSで管理したままZimaOSのFilesアプリ内に表示できるようにすることでした。
彼はメモリ使用状況の見え方に関する別の問題も見つけました。ZFS ARCが空いているメモリを埋めていると、ZimaOSはRAMの大部分を「使用中」と報告することがあります。次に注目したのは btop そしてARC統計を合わせて見ると、より有用な状況が分かります。キャッシュがメモリを消費しているのは、利用可能なメモリがあるためであり、アプリケーションがより多くのメモリを必要とすればZFSはキャッシュを解放できます。
これは、Pioneerビルドで重要な意味を持つフィードバックです。TedはZimaOSで何が動作するかを示しているだけでなく、高度なストレージ構成が現在のUIの限界に達する箇所と、そこに到達したときの対処方法も記録しています。
既存のImmichライブラリを履歴ごと失わずに移行する
かけがえのないデータを保存し始めて初めて、ストレージアーキテクチャの意義はより明確になります。
Tedにとって、そのテスト対象がImmichでした。彼はすでに古いDIY ZimaOSサーバーでImmichインスタンスを運用しており、最初からやり直すことなくZimaCube 2へ移行したいと考えていました。
移行対象は写真14,505枚と動画925本、合計134 GiBでした。しかし重要なデータは画像ファイルだけではありません。アルバム、人物、顔認識、メモリー、共有リンクなどのメタデータはPostgreSQLに保存されていました。
が含まれます。LAN経由でZimaOSのFilesアプリを使い、tedは両方をコピーしました。 /DATA/Gallery/immich と完全な /DATA/AppData/immich ディレクトリ。そこには pgdata。コピーを開始する前に移行元のImmichインスタンスを停止し、PostgreSQLデータの整合性を維持しました。
移行後も、アカウント、アルバム、顔情報、メモリー、ライブラリは完全に維持され、報告されたデータ損失はありませんでした。その後Tedは、ログインに成功したからといってすべてが無事に移行されたと判断せず、PostgreSQLデータベースを直接検証しました。
同じような移行を計画している場合は、ZimaCube 2向けImmich移行ガイドで、同じ重要なポイントを詳しく説明しています。メディアライブラリだけを移行しても不十分で、データベースも一緒に移行する必要があります。
134 GiBの移行から725 GiBのセルフホスト型写真・動画ライブラリへ
Immichのフェーズは、旧サーバーの移行が成功した時点で終わったわけではありません。
既存のZimaOSライブラリの移行として始まった作業は、tedが写真や動画の主な保存先としてiCloudを使うことから大きく離れる転換へと発展しました。彼のiPhoneは、iCloudライブラリのオリジナルデータをZimaCube 2上で動作するImmichへ転送し始めました。
そのフェーズの終了時点で、サーバーには合計725 GiB、63,665個のアセットが保存されていました。その内訳は写真55,604枚、動画8,061本です。iCloudからの転送自体は約655GBを占め、その大部分を4K動画が占めていました。
目標は、Appleのクラウドサービスをすべて置き換えられると装うことではありませんでした。Tedは、デバイスのバックアップやメッセージなど、より小容量のiCloudプランに残しておくのが合理的なiOS固有データも特定しています。変更の焦点はより明確でした。大量の写真と動画のライブラリを自分で管理するストレージへ移しつつ、今なお役立つクラウドサービスは維持することです。
その決断によって、新たな責任も生まれました。セルフホスト型の写真ライブラリがクラウドコピーより安全になるのは、適切にバックアップされている場合だけです。そのためTedの移行記録はTrueNAS上の2つ目のコピーにも及び、まだロードマップに残っている、より広範な3-2-1バックアップフェーズの土台を築いています。
ZimaOSが簡単にすることを軸に構築し、残りを測定する
TedがZimaOSを意図的に選んだのは、Synologyを長年使い、CasaOSの長年のユーザーでもあったためです。よりすっきりしたDocker中心のアプリケーションモデルを求めながら、構築でより高度な作業が必要になったときには基盤システムにもアクセスできる状態を維持したいと考えました。
プロジェクトのいくつかの部分では、このバランスを活用しています。組み込みのAppData移行ツールにより、すべてのアプリを再構築することなく、DockerアプリケーションのデータをシステムドライブからArctic-Storageへ移動できました。Filesアプリは、Immich移行に使用したLANワークフローを提供しました。ネイティブツールには、 fio, zpool, zfs, nvme、そして iostat グラフィカル層の下でストレージアーキテクチャを測定・管理できるようにしました。
一方で、統合がまだ十分でない部分も見えてきます。CLIで作成したZFSストレージにはシンボリックリンクによる回避策が必要です。ARCによって、標準的なRAM容量の数値は誤解しやすくなっています。Thunderboltの挙動を受けて、ハードウェアの再設計も必要になりました。
こうした点から、このプロジェクトはすべての実験が最初からうまくいくショーケースよりも価値のあるものになっています。Tedは、シンプルなZimaOS体験と、そこから一歩踏み込んだときに始まる本格的なホームラボ作業との境界線を記録しています。
すでに構築されているもの — そして今後のロードマップ
tedのリポジトリのタイトルでは、目指す先をAI搭載の控えめなNASと説明していますが、プロジェクトは意図的に段階を分けて構築されています。
基盤はすでに実用段階にあります。 階層型ストレージが稼働しています。glacier ZFS RAIDZ1プールは運用中です。Arctic-StorageはオンボードのM.2スロットに移行しました。メモリは32GBのデュアルチャネル構成になっています。IronWolf RAID5プールも存在します。ストレージのベンチマークは完了しました。Immichの移行と、iCloud写真のより広範な統合も完了しています。
メディア層はまだ拡張中です。 IronWolfプールは大容量メディア用に作成されましたが、Jellyfinとより広範な*arrスタックは、現在のフェーズ2の作業に含まれています。
AIの各レイヤーはまだこれからです。 Tedのロードマップでは現在、フェーズ4aにCPUのみで動作するOllamaのテストを配置し、その後のフェーズ4bでRTX 4090 eGPU構成、フェーズ5でローカルストレージ全体のセマンティック検索を予定しています。
この違いは重要です。ZimaCube 2は、ストレージの配置、メモリ容量、PCIeに関する判断、ワークロード計画を通じて、すでにローカルAIに向けた準備が進められています。しかし、GPU推論を完了した成果として紹介できる段階にはまだ達していません。
この将来の方向性を今から検討している読者に向けて、当社のZimaCube 2でのローカルAIガイドでは、Ollama、メモリ、PCIe拡張、そして将来的なGPUアップグレードを、同様のホームラボのロードマップにどう組み込めるかを解説しています。
証拠が変われば、ビルドも変わる
tedのプロジェクトで最も一貫しているのは、ZFSやImmich、あるいは特定のハードウェアではありません。実際に何が起きたのかを測定した後で、決定を変更する姿勢です。
Thunderboltエンクロージャーが動作しなかったため、ストレージの接続経路はOCuLinkへ移行しました。
P510は7th Bayで性能を活かせなかったため、オンボードのM.2スロットへ移されました。
ZFS ARCは予想以上の性能を発揮したため、メモリは単なる容量の追加ではなく、パフォーマンス向上の手段になりました。
134 GiBのImmich移行はデータベースを失うことなく完了し、その結果、iCloudからさらに数百GBを移行する実験へと発展しました。
各フェーズには、次のフェーズに向けた測定結果、コマンド、失敗、更新された前提が残されます。そのため、まったく同じストレージ構成を構築しない人にとっても、このリポジトリは役立ちます。
物語は今も書き継がれている
ted-knightとZimaの物語は、今も書き継がれています。 ZimaCube 2は8GBのStandardモデルとして始まり、すでにbtrfs、ZFS RAIDZ1、OCuLinkによるNVMe拡張、32GBデュアルチャネルメモリ、IronWolf RAID5アーカイブ、そして数百GBの個人メディアを保存するセルフホスト型Immichライブラリを備えたマルチティアストレージシステムへと進化しています。
次のフェーズは意図的にまだ開かれています。Jellyfinとメディアスタック、より強固なバックアップワークフロー、CPUのみで動作するローカルAI、将来的なGPU構成、セマンティック検索、そして途中での測定結果によってtedが再検討を迫られるあらゆる要素が含まれます。
フェーズがロードマップから実際の成果へと進む過程を追いたい方は、GitHubでted-knightの進行中のZimaCube 2ビルドをフォローしてください。
