コンピューティング
専用サーバー ハードウェアは、ストレージ、コンテナ、メディア サービス、ネットワーキング ツール、およびインフラストラクチャ実験の基盤を提供します。
← プロジェクトに戻る
インフラ
インフラとシステムのラボ
ストレージ、Linux、コンテナ、メディア サービス、ネットワーキング、権限、トラブルシューティング、リカバリ、および実践的なシステム管理のための長期実行インフラストラクチャ環境。
TrueNASZFSLinuxDockerプレックスネットワーキングストレージ回復
プロジェクト概要
運用中のラボ- 目的
- ストレージ、ネットワーキング、Linux、コンテナ、リモート アクセス、モニタリング、復元力、インフラストラクチャ障害のトラブルシューティングのための実践的な環境。
- 私の役割
- 個人ラボの調査、設計、ドキュメント作成。
- 実装状況
- 既存のケーススタディには、TrueNAS および ZFS ストレージ、Linux とコンテナー サービス、リモート アクセス、およびトラブルシューティングが文書化されています。より強力なネットワーク セグメンテーションは依然として進化しています。
- 次のマイルストーン
- サニタイズされたトポロジ、観察されたタイミングによる回復演習、および反復可能なサービス健全性チェックリストを公開します。
実装リポジトリ：未公開。
証拠と結果
作品が示すもの
運用中のラボ既存のケーススタディには、TrueNAS および ZFS ストレージ、Linux とコンテナー サービス、リモート アクセス、およびトラブルシューティングが文書化されています。より強力なネットワーク セグメンテーションは依然として進化しています。
クライアント · リモート アクセス
ネットワーク接続
Linux · コンテナ サービス
TrueNAS · ZFS ストレージ
記録された作業
- ZFS ARC キャッシュの増加は、メモリ障害として扱われるのではなく、コンテキスト内で評価されました。
- ストレージ パス、アクセス許可、コンテナーの依存関係、およびサービスの回復は、トラブルシューティングの問題として文書化されています。
次に公開する証拠
サニタイズされたトポロジ、観察されたタイミングによる回復演習、および反復可能なサービス健全性チェックリストを公開します。
ソース リンクには、別の実装リポジトリではなく、この公開されたケース スタディが含まれています。
概要
私が運用、破壊、再構築できるインフラストラクチャ
このラボでは、ストレージ、ネットワーク、アプリケーション、Linux、コンテナー、メディア サービスがすべて相互に依存する環境を提供しています。
ハードウェアの変更、ストレージの移行、アプリケーションの障害、権限の問題、メディア ライブラリの問題、ネットワークのトラブルシューティング、およびさまざまなセルフホスト サービスの実験を通じて進化してきました。
プラットフォームの価値は単一のアプリケーションではありません。これは、レイヤー全体で障害を診断する必要があり、展開と同じくらい回復が重要であるインフラストラクチャを実行する経験です。
建築
連携するシステム
ストレージ
ZFS プールとデータセットは、メディア、アプリケーション、バックアップ、長期データ管理のためのコア ストレージ層を提供します。
サービス
コンテナ化されたセルフホスト型アプリケーションは、デスクトップ環境に関連付けられるのではなく、マネージド サービスとして実行されます。
ネットワーク
高速ネットワーキングは、ラボをクライアント、リモート管理ツール、メディア デバイス、その他の環境に接続します。
ハードウェア
現在のインフラストラクチャ プラットフォーム
CPU
Intel Xeon E5-2699 v4
マザーボード
ASUS X99-DELUXE II
記憶
128 GB DDR4
GPU
デュアル NVIDIA T400 4 GB
ストレージ
6 × 8 TB ヘリウム HDD
ソリッドステート
NVMe + SATA SSD
ファイルシステム
ZFS
プラットフォーム
TrueNAS
一次用途
ストレージ、メディア、コンテナ、ラボ サービス
実践的な作業
ラボの運営
実際のサービスは実際の依存関係を作成します。ストレージ、権限、ネットワーキング、コンテナ、アプリケーション、リカバリがすべて重要であるため、このプラットフォームは学習に役立ちます。
TrueNAS と ZFS
ストレージ プール、データセット、権限、スナップショット、アプリケーション ストレージ、環境全体の容量を管理します。
Plex メディア サービス
ストレージ、トランスコーディング、メタデータ、クライアント アクセス、ライブラリ管理要件を備えたセルフホスト型メディア サービスを運用します。
コンテナとアプリケーション
永続ストレージ、ネットワーキング、アクセス許可、更新、およびサービスの健全性に依存するコンテナ化されたサービスを実行します。
Linux 管理
コマンドライン管理、サービス管理、ログ、権限、トラブルシューティングを使用して環境を維持します。
ネットワーキング
ローカル アドレス指定、高速接続、リモート アクセス、サービス到達可能性、およびセグメント化計画を処理します。
回復
スナップショット、ドキュメント、バックアップ、再構築手順を、失敗後に追加されたものではなく、設計の一部として扱います。
ストレージ
基盤としての ZFS
保管は研究室の基礎です。メディアサービス、コンテナ、アプリケーションデータ、構成、および長期ファイルはすべて、基盤となる ZFS 環境に依存します。
ZFS を使用するには、ディスク容量以上の理解が必要です。プール、データセット、権限、キャッシュ、スナップショット、ワークロードの動作はすべて、システムの動作に影響します。
有益な教訓の 1 つは、大量のメモリ消費が自動的に問題になるわけではないということです。 ZFS ARC は、キャッシュに利用可能なメモリを積極的に使用するため、システムの健全性は、単一の使用率の数値を調べるのではなく、コンテキストに基づいて評価する必要があります。
トラブルシューティング
失敗も研究室の一部
最も役立つインフラストラクチャの教訓のいくつかは、サービス、ストレージ、アクセス許可、またはアプリケーションの統合が期待どおりに動作しなかった瞬間から得られます。
トラブルシューティングのアプローチ
複数のレイヤーを一度に変更する前に、ストレージ、ネットワーキング、権限、コンテナ、アプリケーション、およびクライアントの動作を分離します。
アプリケーションの再起動
問題
Containerized services and hosted applications can fail, restart unexpectedly, or become unavailable after configuration changes.
応答
Review service state, logs, storage dependencies, permissions, and configuration rather than assuming the application itself is the only failure point.
ZFS メモリの動作
問題
ZFS can consume significant system memory for ARC caching, which can look like abnormal RAM usage if the behavior is not understood.
応答
Validated that cache growth is expected behavior and evaluated system memory in the context of ZFS rather than treating all used RAM as a fault.
Plex ライブラリの問題
問題
Media libraries can develop duplicates, missing items, metadata mismatches, or inconsistent paths.
応答
Worked through library paths, naming, metadata, scans, storage layout, and application behavior to isolate the source of inconsistencies.
アプリケーションの統合
問題
Supporting services such as Tautulli or Bazarr may fail even when the core media server remains operational.
応答
Validated networking, API connectivity, application configuration, storage access, and dependencies independently.
権限
問題
Datasets, containers, users, and applications can require different ownership and access patterns.
応答
Treat file permissions and application access as an infrastructure layer that must be designed and tested rather than guessed at.
依存関係のマッピング
問題
A single visible failure can originate in storage, networking, containers, permissions, or another supporting service.
応答
Use layer-by-layer diagnosis to identify the real dependency causing the failure before making changes.
セキュリティ
制御可能なインフラストラクチャ
ストレージおよびセルフホスト サービスは、アクセス許可、ネットワークへの露出、管理アクセス、および回復に関する独自のセキュリティ要件を作成します。
アクセス分離
管理アクセスとアプリケーション アクセスは別個の関心事として扱われるため、サービスは不必要な特権を必要としません。
データセットの権限
ストレージのアクセス許可は意図的に管理されているため、アプリケーション、ユーザー、サービスは必要なアクセスのみを受け取ります。
サービスの分離
コンテナーと分離されたアプリケーションにより、単一のランタイム環境を共有する必要があるサービスの数が減ります。
ネットワーク境界
ラボは、インフラストラクチャ、クライアント デバイス、管理インターフェイス、公開サービスの間のより強力なセグメンテーションに向けて進化し続けています。
リモート管理
リモート アクセスは、ストレージ管理をパブリック インターネットに直接公開するのではなく、制御された管理パスを通じて処理されます。
復興計画
スナップショット、構成文書、および再構築の考え方により、間違い、更新の失敗、またはサービスの破損の影響が軽減されます。
学んだ教訓
Infrastructure Is About Dependencies
01
ストレージ アーキテクチャは、その上に階層化されているほぼすべてのサービスに影響を与えます。
02
健全なインフラストラクチャ プラットフォームには、個々のアプリケーションだけでなく、依存関係を理解する必要があります。
03
ZFS の動作は、メモリ、キャッシュ、データセット、ワークロード パターンを合わせて考慮するとより合理的になります。
04
メディア サービスとコンテナ サービスは、実際のストレージ、ネットワーク、アクセス許可、および回復の問題を解決する必要があるため、便利です。
05
環境が拡大するにつれて、文書化と再現可能なリカバリ手順の価値が高まります。
次のステップ
Where the Lab Goes Next
01
ネットワークのセグメンテーションを改善する
02
インフラストラクチャ監視の拡張
03
バックアップとリカバリのドキュメントを強化する
04
コンテナのデプロイパターンを標準化する
05
アプリケーションの健全性の可視性を向上させる
06
ストレージとパフォーマンスのチューニングを継続する
さらなるプロジェクト