FrameworkノートPCとディスクで10TBのS3を直接ホスティングする

• FrameworkノートPCとJBODを活用して独自のS3ストレージを構築し、10TBの容量を低コストで運用しており、4か月間ほぼ放置でも安定して稼働
• 画面のない中古のFrameworkノートPCにZFSとgarage S3を導入してホームサーバーとして活用し、AppGoblinのSDK追跡プロジェクト向けの大容量ストレージとして使用中
• 4か月間サーバーをまったく気にしていなかったが、ログインしてみると10TBが使用され、アップグレード待ち状態になっており、再起動後もすべて正常に動作
• garage S3のv1からv2へのアップグレードも問題なく完了し、安定した運用を確認
• USBでノートPCとJBODを接続する非標準的なZFS構成で当初は問題があったが、メタデータをノートPC内部に移して解決

---

プロジェクトの背景と動機

• 5か月前に独自S3ホスティングを決定
  • AppGoblinの上位10万件のAndroidおよびiOSアプリのSDK追跡作業を進行中
  • 大容量の保存領域が必要だったが、コストは抑えたかった
  • 既存のクラウドS3ではなくセルフホスティング方式を選択

ハードウェア構成

• FrameworkノートPCを活用
  • 画面のない中古のFrameworkノートPCを安価に購入
  • 旧型モデルのため、ホームサーバー用途に適していた
  • ノートPCの携帯性と低消費電力の特性を活用
• JBOD（Just a Bunch of Disks）を追加
  • 大容量保存のための外付けディスクアレイ
  • USB経由でノートPCに接続

ソフトウェアスタック

• ZFSファイルシステム
  • データ整合性とスナップショット機能を提供
  • JBODをZFSプールとして構成
• garage S3
  • 軽量な分散S3互換ストレージソリューション
  • Deuxfleursが開発したオープンソースプロジェクト
  • S3 API互換性を提供

4か月間の無管理運用

• 設置後4か月間、サーバーをまったく気にしなかった
  • 旅行や仕事、忙しい日常の中でもS3は継続的に利用されていた
  • サーバーについて考える必要がなかった
• ログイン後にわかったこと
  • 10TBの保存領域が使用されていた
  • システムはアップグレードのための再起動を辛抱強く待っていた
• 再起動の結果
  • 緊張しながら再起動を実行
  • すべてが正常に再稼働し、ほっとした

garage S3のアップグレード

• v1からv2へのアップグレード
  • 保留されていたメジャーバージョンアップを発見
  • アップグレード作業は問題なく進行
  • 良い週末だったと評価

技術的な注意点と解決策

• 非標準的なZFS構成への認識
  • USB経由でノートPCとJBODを接続するのは、やや非標準的なZFSの利用例
  • Redditコミュニティからこの点について警告を受けた
• 初期の問題発生
  • garageが大量の読み書きを行う際にZFSの問題が発生
  • 初期設定ではSQLiteのメタデータもJBOD/ZFS上に保存されていた
• 問題の解決
  • メタデータをノートPCの内部ストレージへ移動
  • その後はZFSの問題が解消し、安定して動作

[shakespeares]

セルフホスティングに挑戦すること自体がすごいです。

[rtyu1120]

価格帯にはかなり差がありますが、Frameworkのメインボードは現代のRaspberry Piになったようですね

[GN⁺]

Hacker News の意見

• 画面なしでメインボードだけなら、CoolerMaster のような専用ケースに入れることもできる CoolerMaster Framework ケースのリンク
  • これ、本当にすごく良い。でも自分が強調したかったのは、このノートPC自体がとてもよく動くという点。ファンの音もしないし発熱もほとんどなく、低負荷時の消費電力も本当に優秀で、そういう点がこの用途にぴったりだと思う
  • Framework マーケットプレイスでもケースのリンクが共有されている Framework マーケットプレイスのケースリンク。古いメインボードをこのケースに入れてアップグレードしたことがあり、VESA マウントでモニターの裏に付けてデスクトップPCとしても使い、今は HTPC（ホームシアターPC）として使っている。とても満足している
  • 10インチのミニラックも良い代替案 DeskPi RackMate 10インチ ミニラック
• 技術的な部分がもっと気になる。まったく同じ構成をそのまま再現したいというより、ZFS プールをどう組んだのか、そして Garage がそのあたりを自動でやってくれるのか、ミラー構成なのか、それとも単なる個別プール同士を別ディスク間で同期する形なのかが知りたい。自分は USB ディスク 2台で安価に NAS を作りたいのだけど、ZFS ミラーにするか、独立した 2つのプールを作って片方をもう片方のバックアップ用にするか、あるいは SnapRAID にして古い HDD を混在させハードウェア活用を最大化するかで悩んでいる
  • ZFS ミラーと独立プールで迷っているなら、ミラーにするとビットロット保護と自動修復機能（スクラブ）が得られ、読み取り速度も速くなる。容量が近い HDD が2台あれば、ZFS でミラー vdev を既存プールに追加することも、新しいバックアッププールを作ることもできる。ミラーに入れる2台同士の容量が近ければよく、プール内の全ディスクが同じである必要はない
  • Garage は特定の方式に縛られない設計で、ZFS なしでも十分動作する。Ubuntu に ZFS を別途入れてから Garage をインストールした。ZFS はシンプルに RAID5/raidz1 で組んでいる。専門家ではないが、使用率が 33% に近づいてきたので、この点は見直し中。こうした悩みで、以前 HN で見た魔法のようなコメントを思い出した。「重要なデータの一部については数時間分の損失を許容できると考え、ミラーではなく独立した1ディスクプールを2つ作り、メインプールで数時間ごとにスナップショットを取り、zfs send/recv でバックアッププールへ送る」というもの。このフローのほうが自分の用途には合っていそうで、もともと RAID5 はディスク1台の故障対策のためだったが、同じ構成を別拠点にも置こうとするとコストがかなりかかる（約 $1,000 USD）ため、まだ実行できていない
• Garage というものを今回初めて知ったが、かなり興味深い。仕事では S3 をよく使っていて、個人のホームラボのバックアップは borgbase で borg を使ってきた。今回、garage を使ってローカルノードと AWS glacier を組み合わせ、大容量メディアライブラリを安価に冗長保存する方法が可能なのか気になっている。すべての読み取りトラフィックがローカルノードから処理されるのかも知りたい。TFA では実際の Garage 利用経験の話があまりなかったので、実際にセルフホスト目的で使っている人の意見を聞いてみたい。編集: glacier には使えないことが分かった。Garage バイナリを実行する EC2 インスタンス上でファイルシステムとしてマウントされている必要があるため。単に borg/restic で glacier へのバックアップをスケジュールしたほうがよい
  • 別の代替案として ZeroFS がある。データを S3 に直接保存できる ZeroFS GitHub
  • AWS S3 と連携し、積極的なライフサイクルポリシーを設定して、短期間後にデータを glacier へ自動移行させることもできる。以前の職場でこの方法を使ったことがあり、数日後に標準ストレージから glacier へ移すようにしていた。自分のケースなら X を 1日にすればよい
  • Garage 自体を直接触る必要はほとんどなかった。awscli、s3cmd、rclone、Boto3 のような S3 API ツールで十分活用できた。Garage はほんの数個のコマンドで簡単にセットアップでき、一度動かせば4か月間ずっと問題なく回り続けた。この点でとても満足している
• 静かで成功しているセルフホスティング事例を共有したかった
  • この JBOD は SSD 構成なのだろうか。その台数の HDD だとかなりうるさい可能性がある
  • 昔は「自分でコンピューターを所有して何かを動かすこと」が『セルフホスティング』という言葉で呼ばれるのが妙に感じられた。今ではすべてのコンピューターが他人のものになった時代のようで、だから自分で使っていることをわざわざ特記しなければならない時代なのだと思う
• 自分なら、古い Dell T30 に 10TB の Seagate Exos を2台入れて ZFS RAID1（ミラー）にしたほうが、より安全に感じると思う。提案されている方式は、毎日バックアップを取っていても毎回不安になりそうだ。Dell T30 も完璧に安心というわけではないが、それでもディスクを別の機器に接続しやすいし、ケーブルが簡単に抜ける心配も少ない。それでも Garage はかなり良さそうなので感謝している
  • 自分も ZFS をかなり長く使ってきたが、多くのデータについては数時間程度の損失は許容できるという結論に達した。そこでミラーではなく、独立した1ディスクプールを2つ作り、メインプールで数時間ごとに自動スナップショット → zfs send/recv でバックアッププールへ複製する構成にしている。これにより柔軟にディスクを混在使用できる（たとえば一方は SSD、もう一方は HDD など）。ただし、読み取り速度と可用時間では妥協が必要。外付け HDD をバックアップディスクにして、数日おきに接続する方法もある。重要なデータについては別にミラー構成の RAID プールを持っている。ZFS の記事は RAID に注目したものが多いが、上で述べたようなハードウェアを最小限にした構成については情報が少ない気がする
• Framework がここで特別に何かをもたらしているのかはよく分からない。自分は RPi5 にディスクを何台かつないで似たような規模でホスティングしている。ZFS の代わりに lvm2 を使っているが、RPi5 でも問題なく動いている。ZFS はメモリを使いすぎるので、この用途には向いていない
• Garage は本当に気に入っている。放っておいてもちゃんと動く。古い Odroid HC2 を数台使って、k8s の Velero バックアップ用に Garage を動かしているが、設定後は手を入れなくても勝手に維持されている
• Garage の話題が出てうれしい。自分も S3 互換のセルフホスト代替を決めるとき、Garage と SeaweedFS で迷った。自分の経験では、SeaweedFS のほうが Garage より手動設定が少なくて済み、より楽だった
• すばらしい結果だ。自分も Framework のメインボードを交換して、NAS バックアップ専用に活用しようとしている。zfs のセットアップについてもう少し詳しく聞きたい。スナップショット専用の保存先としてだけ使いたいのだが、USB 接続速度や誤って取り外してしまったときにデータを失いそうなのが心配だ
• Garage に関する以前の議論がある Hacker News Previous Discussion