RG 4 TechがZimaBoard 2でプライベートクラウドを構築する方法

RG 4 Techは、ZimaBoard 2を単なるコンパクトなファイルサーバー以上のものに仕上げています。この構成では、静音性に優れたx86ハードウェア、直接接続した2台のドライブ、ZimaOSのRAID 1ストレージプール、Home Assistantを、ブラウザで管理できる1つのシステムに統合しています。その結果、ファイルとスマートホームサービスのための実用的なプライベートクラウド基盤が実現します。ただし、独立したバックアップと、Home Assistant ContainerとHome Assistant OSの違いを踏まえた導入計画は依然として必要です。

完全なセットアップを記録してくれたRG 4 Techに感謝します。彼の元の動画では、ハードウェア、内部冷却、ZimaOSの初期設定、2台のドライブによるRAID 1の構成、アプリケーションのインストール、Home Assistantの初期設定まで詳しく紹介されています。

出典に関する注記： この記事では、RG 4 Techの動画で紹介された構成と所見を再構成しています。この動画に登場するすべてのデバイスがZimaSpaceから提供されたものだとは想定していません。ここでは、そのような提携関係が独自に確認されていないためです。インターフェースの詳細、アプリケーションのバージョン、利用可能なバンドル、温度、互換性は、公開後に変更される場合があります。

結果： ZimaBoard 2により、RG 4 Techはローカルストレージとスマートホーム制御を1台の薄型プラットフォームに集約できます。RAID 1によって、構成ドライブの1台に障害が発生してもストレージプールを利用可能な状態に保てます。また、Home Assistantがローカル自動化レイヤーを追加します。ただし、どちらの機能も、重要なデータと設定をサーバーの外部にバックアップする必要性をなくすものではありません。

RG 4 Techがローカルホームサーバーから始める理由

この動画の「クラウドに別れを告げる」という趣旨は、単に月額料金を避けることではありません。ホームサーバーによって、ストレージハードウェアを誰が管理するのか、どのアプリケーションがデータを処理するのか、サービスをネットワークにどう公開するのか、容量をいつ拡張するのかが変わります。個人ファイルやスマートホームのアクティビティが複数のプロバイダーに分散されている場合、こうした選択は特に重要になります。

ローカルで所有することは、責任も引き受けることを意味します。所有者はドライブの状態を監視し、アップデートを適用し、ユーザーアクセスを管理し、バックアップを維持し、障害発生後にサービスを復旧しなければなりません。したがってプライベートクラウドとは、プロバイダーだけを取り除いたクラウドサービスではなく、運用計画を必要とする小規模なインフラです。

RG 4 Techは、ZimaBoard 2を密閉型のアプライアンスではなく、柔軟な基盤として捉えています。このボードはストレージサーバーとして使い始め、ZimaOSを通じて追加のアプリケーションをホストできるため、実際の家庭の運用に合わせてシステムを拡張できます。

ZimaBoard 2がこの構成に適している理由

ZimaBoard 2 ミニホームサーバー は、Intel N150プロセッサー、オンボードメモリとシステムストレージ、2つの2.5GbEポート、2つのSATA接続、オープンなPCIe拡張インターフェースを備えています。この組み合わせが重要なのは、ホームサーバーに必要なのはCPU性能だけではなく、ストレージ、ネットワーク、将来のハードウェアに対応する実用的な接続手段だからです。

2つのSATAポートにより、USBストレージブリッジに頼らず、HDDまたはSSDを2台直接接続できます。デュアルネットワークインターフェースは、ストレージリンク、ネットワークの分離、ルータープロジェクト、または1つのポートでは制約が生じる別のトポロジーに対応できます。PCIeには、NVMeストレージなど、用途に応じて選んだ拡張機器を追加できる余地があります。

プラットフォームは依然としてコンパクトです。1本のPCIeパスですべての拡張カードを同時に搭載できるわけではなく、2つのSATAポートで多ベイNASを構築できるわけでもありません。また、Intel N150を多コア仮想化向けプロセッサーとして扱うべきでもありません。この設計は、アクセサリーを追加する前にサーバーの主な役割を決めておくと最も効果を発揮します。

筐体を開くと冷却戦略が分かる

08:16、RG 4 TechはZimaBoard 2の筐体を開き、内部の基板レイアウトとアクティブ冷却に使用する位置を紹介します。この映像は、完成した外観だけではプロセッサーや周辺コンポーネントから熱がどのように逃げるのか分からないため、役立ちます。

アルミニウム構造は放熱に貢献し、ボードを暖かい場所に設置した場合や、より重い処理を継続的に行わせる場合には、ファンで airflow を追加できます。ストレージの稼働状況、アプリケーションのインデックス作成、室温、ケーブルの配置、周囲の表面状態など、実際の設置環境における熱条件にはさまざまな要素が影響します。

アクティブ冷却は、装飾ではなく負荷に応じて決めるものです。軽い負荷のファイルサーバーは、ストレージ転送、アプリケーションの更新、メディアのインデックス作成、スマートホームサービスを同時に実行する同じボードとは異なる動作をする可能性があります。組み立て後は、アイドル時の温度だけに頼らず、想定する複合負荷をかけた状態で温度を確認してください。

プールを作成する前に物理ストレージを計画する

RG 4 Techは、ZimaOSでストレージを構成する前に2台のドライブを接続します。この順番は当然のように思えますが、重要なミスを防ぎます。つまり、共有フォルダーを作成したりアプリケーションをインストールしたりする前に、どのディスクにアクティブなデータを保存するのか、どのディスクを冗長化に使うのか、バックアップをどこに保存するのかを決められるのです。

2台のドライブを搭載したサーバーでは、いくつかのレイアウトを選択できます。ディスクを独立して使用することも、パフォーマンスや容量のために結合することも、冗長性のためにミラーリングすることも可能です。適切な選択は、使用可能な容量、ドライブ障害後も継続して利用できること、異なるデータクラスを分離することのいずれを優先するかによって決まります。

ドライブの組み合わせにも注意が必要です。ミラーリングでは通常、容量の小さいメンバーを基準に容量が決まるため、サイズが大きく異なるドライブを組み合わせると容量を無駄にする可能性があります。新しいプールに重要なデータを移す前に、両方のドライブをテストし、状態を監視して、シリアル番号を記録しておく必要があります。

ZimaOSで2台のドライブによるRAID 1プールを作成する

16:50、RG 4 TechはZimaOSのストレージインターフェースを使って2台のディスクを選択し、RAID 1を設定します。このレイアウトでは、メンバードライブ間にミラーコピーを書き込み、1台のドライブが故障した場合でもプールを利用し続けられる代わりに、合計の raw 容量の半分を使用します。

ZimaOSでは、ZimaOS RAIDオプションガイドで、冗長化に重点を置いた選択肢としてRAID 1を紹介しています。グラフィカルなワークフローにより、ユーザーはドライブを識別してストレージモードを選択できるため、コマンドラインだけでアレイ全体を構築する必要がなく、初めてNASを導入する際のハードルが下がります。

インターフェースを使っても、選択内容の確認が不要になるわけではありません。新しいアレイを作成すると、選択したディスク上の既存データが消去される可能性があります。最終操作を承認する前に、ドライブの識別情報、容量、必要なコピーがあるかどうかを確認してください。

RAID 1が役立つ理由と、それでもバックアップではない理由

RAID 1が対処するのは、メンバードライブ1台の喪失という特定の障害です。1台のディスクが動作しなくなっても、故障したデバイスを交換してアレイを再構築する間、もう一方のコピーによってプールへのアクセスを維持できます。常時オンラインであることが求められるサーバーにとって、この可用性は重要です。

ミラーリングでは、論理的な変更が両方のドライブに繰り返し適用されます。そのため、誤った削除、ファイルの上書き、ランサムウェア攻撃、アプリケーション状態の破損、管理者コマンドの誤操作が、両方のコピーに影響する可能性があります。盗難、電気的な損傷、サーバー全体の物理的な紛失によって、アレイ全体が一度に失われることもあります。

より安全な設計では、RAID 1と別の場所に保存するバージョン管理バックアップを組み合わせます。ZimaSpaceのRAIDレイアウトとNASバックアップ計画ガイドでは、冗長化、バックアップ履歴、デバイス外のコピーがそれぞれ異なるリスクに対処する理由を解説しています。

ZimaOSはストレージハードウェアをアプリプラットフォームに変える

プールを利用できるようになれば、サーバーを単なるネットワーク共有として使い続ける必要はありません。ZimaOS はブラウザベースのファイル管理とアプリケーション環境を追加するため、ストレージとセルフホストサービスを同じインターフェースから管理できます。

ここで、ハードウェアは2ベイのディスクエンクロージャー以上の価値を発揮します。アプリケーションはローカルプールを永続ファイル用に使用でき、オペレーティング環境がそのライフサイクルを管理します。家庭ではファイルストレージから始め、初日に完全なホームラボのスタックをデプロイするのではなく、一度に1つずつサービスを追加できます。

アプリケーションデータを、見えないインフラにしてはなりません。サービスをインストールする前に、その設定ディレクトリ、データベース、アップロードファイル、ネットワークポート、バックアップ方法を確認してください。実行中のコンテナは簡単に再作成できますが、その中の状態まで再現できるとは限りません。

Home Assistant のインストールでローカルなスマートホーム制御を追加

19:07、Home Assistant が起動し、RG 4 Tech は初期オンボーディング画面に到達します。これにより、ZimaBoard 2 がストレージ環境と並行してアプリケーションをホストできることが確認され、このプロジェクトにもう一つの明確な役割が加わります。それは、互換性のあるスマートホームデバイスや自動化をローカルで調整することです。

Home Assistant を使えば、すべての自動化をベンダーのクラウド経由で実行するのではなく、多くの処理をホームネットワーク内で完結できます。ただし、実際にどの程度ローカルで制御できるかは、デバイスやインテグレーションごとに異なります。ローカル API を公開する製品もあれば、外部アカウントやクラウド接続を引き続き必要とする製品もあります。

最初の画面はデプロイの始まりであり、完了ではありません。システムを安定して運用できる状態にするには、所有者が管理者アカウントを作成し、自宅の場所を設定し、検出されたデバイスを確認し、安全なリモートアクセスを確保し、自動化をテストし、バックアップのスケジュールを設定する必要があります。

Home Assistant Container と Home Assistant OS は異なる選択肢

既存のアプリケーションプラットフォームを通じて Home Assistant をインストールする場合、通常は Home Assistant Container を実行することになります。公式の Home Assistant のインストール概要では、コンテナ方式がユーザー管理のホストおよびコンテナ環境を使用することを説明しています。また、Home Assistant OS で利用できるアプリシステムは含まれていません。

コンテナのデプロイは、多目的な ZimaOS サーバーに適しています。Home Assistant をストレージやその他のアプリケーションと共存させられるためです。Home Assistant OS は、マシン全体を Home Assistant 専用にし、統合された管理エクスペリエンスを求めるユーザーにとって、よりアプライアンスに近い選択肢です。

RG 4 Techのアプローチは、役割を統合できる点で魅力的です。ただし、障害の影響範囲とのバランスを考える必要があります。共有サーバーの再起動や修復によって、ファイルアクセスとスマートホーム制御の両方が一時的に影響を受ける可能性があります。

ストレージサービスとスマートホームサービスには個別の復旧計画が必要

ミラーリングされたストレージプールと稼働中のHome Assistantインスタンスは、それぞれ異なるものを保護します。RAID 1は、プールがメンバードライブの故障に耐えられるようにします。Home Assistantのバックアップは、設定、オートメーション、対応アプリケーションの状態を保持します。ただし、どちらもサーバー外部の安全なコピーを自動的に作成するものではありません。

Home Assistantは現在、バックアップ統合のドキュメントに記載されているように、インストール方式をまたいだバックアップの作成と復元に対応しています。これらのバックアップは、同じ2台のディスクアレイや同じ物理マシンに依存しない保存先へコピーする必要があります。

実用的な復旧テストでは、2つの問いを分けて考えます。NASを失った後、家庭内のファイルを復元できるか。そして、アプリケーションホストを失った後、Home Assistantを復元できるか。両方の答えが、同じサーバーが稼働し続けることに依存するなら、そのシステムには依然として単一の障害ドメインがあります。

この統合サーバーが得意なこと

同じようなZimaBoard 2サーバーを構築すべき人

この構成は、初めてプライベートクラウドを構築したい人、2台のドライブで家庭用NASを作りたい人、ローカルのスマートホームコントローラーを求める人、または役割ごとに別のコンピューターを用意せず、コンパクトなアプリケーションホストを構築したい人に適しています。洗練された密閉型アプライアンスのデザインよりも、静かな動作とオープンなハードウェア拡張性を重視する場合に、特に魅力的です。

NASのメンテナンス中もオートメーションを利用可能な状態に保つ必要がある場合は、Home Assistant専用デバイスのほうが適しています。より大容量のストレージ階層、複数の独立したプール、または幅広いドライブ障害への耐性が必要なユーザーには、より大きなマルチベイNASが向いています。多数の大規模な仮想マシンや継続的な計算処理を実行する場合は、より多コアのサーバーが適しています。

判断は、ハードウェアで起動できるアプリの数だけでなく、障害ドメインから始めるべきです。集約によってスペース、電力、管理の手間を削減できますが、再起動やハードウェアの問題が1回発生するだけで、複数の家庭内サービスが同時に中断される可能性もあります。

RG 4 Techが明確な家庭内の用途を中心にプライベートクラウドを構築

RG 4 Techのプロジェクトが成功しているのは、主要な手順のすべてに目的があるからです。シャーシを開くことで、冷却とメンテナンスの経路が明らかになります。2台のドライブを接続することで、ストレージの基盤が整います。RAID 1はディスク障害後の可用性を高めます。ZimaOSによってストレージの管理が容易になり、Home Assistantを導入することで、このマシンをローカルオートメーションにも活用できます。

これらのメリットは、正確に説明されている場合にこそ、この構成の強みになります。RAID 1は冗長化であり、バックアップではありません。Home AssistantコンテナはHome Assistant OSと同一ではありません。静かなサーバー1台で便利な作業を集約できますが、バックアップと復旧計画をサーバーの外部に用意しなければ、リスクも集約されます。

内部ハードウェアの確認、ZimaOSのストレージ設定、RAID 1の運用、Home Assistantのインストールについては、RG 4 Techの完全な動画をご覧ください。ローカルでスマートホームを導入する別の方法については、ZimaBoardでHome Assistantを実行する方法をご覧いただくか、ZimaSpaceのDiscordコミュニティに参加して、ほかのユーザーとホームサーバー構成を比較してください。