计算
专用服务器硬件为存储、容器、媒体服务、网络工具和基础设施实验提供了基础。
← 返回项目
基础设施
基础设施与系统实验室
一个长期运行的基础设施环境，用于存储、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 氦硬盘
固态
NVMe + SATA 固态硬盘
文件系统
ZFS
平台
TrueNAS
主要用途
存储·媒体·容器·实验室服务
实践工作
操作实验室
真正的服务创建真正的依赖关系。这使得该平台对于学习很有用，因为存储、权限、网络、容器、应用程序和恢复都很重要。
第 376 章
管理整个环境的存储池、数据集、权限、快照、应用程序存储和容量。
Plex 媒体服务
运营具有存储、转码、元数据、客户端访问和库管理要求的自托管媒体服务。
容器与应用程序
运行依赖于持久存储、网络、权限、更新和服务运行状况的容器化服务。
Linux 管理
使用命令行管理、服务管理、日志、权限和故障排除来维护环境。
网络
处理本地寻址、高速连接、远程访问、服务可达性和分段规划。
恢复
将快照、文档、备份和重建过程视为设计的一部分，而不是在失败后添加的内容。
存储
ZFS 作为基础
存储是实验室的基础。媒体服务、容器、应用数据、配置和长期文件都依赖于底层的ZFS环境。
使用 ZFS 需要了解的不仅仅是磁盘容量。池、数据集、权限、缓存、快照和工作负载行为都会影响系统的运行方式。
有用的教训之一是认识到高内存消耗并不自动成为问题。 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.
安全
可控制的基础设施
存储和自托管服务围绕权限、网络暴露、管理访问和恢复创建自己的安全要求。
访问分离
管理访问和应用程序访问被视为单独的问题，因此服务不需要不必要的特权。
数据集权限
有意管理存储权限，以便应用程序、用户和服务仅收到他们需要的访问权限。
服务隔离
容器和分离的应用程序减少了必须共享单个运行时环境的服务数量。
网络边界
实验室继续朝着基础设施、客户端设备、管理界面和公开服务之间更强的细分方向发展。
远程管理
远程访问通过受控管理路径进行处理，而不是将存储管理直接暴露给公共互联网。
恢复计划
快照、配置文档和重建思维可减少错误、更新失败或服务损坏的影响。
吸取的教训
基础设施就是依赖
01
存储架构几乎影响其上的所有服务。
02
健康的基础设施平台需要了解依赖关系，而不仅仅是单个应用程序。
03
当内存、缓存、数据集和工作负载模式一起考虑时，ZFS 行为更有意义。
04
媒体和容器服务很有用，因为它们会产生真正需要解决的存储、网络、权限和恢复问题。
05
随着环境的发展，文档和可重复的恢复过程变得更有价值。
下一步
实验室的下一步发展
01
改进网络分段
02
扩大基础设施监控
03
加强备份和恢复文档
04
标准化容器部署模式
05
提高应用程序运行状况可见性
06
继续存储和性能调整
更多项目